java defunct產生的原因和解決辦法

解決 java defunct產生的原因和解決辦法:

在很多時候,我們啟動JAVA進程後,如果退出這個JAVA進程,在系統進程中仍然可以看到這個進程.
這種情況一般出現在UNIX/LINUX系統,對於WIN平台出現情況較少.

這個進程在UNIX平台上,你即使kill進程號也不能殺掉它,但它仍然佔用系統資源,成了真正的"殭屍"。

產生的原因：
以前我們下載JDK時，可以下載到JDK的SRC然後自己編譯，現在的官方網站上已經找不到可以自己編
譯的JDK包，下載回來的JDK都是釋放包，我們可以想象，無論SUN在發布JDK時考慮得如何完美，本地
庫都不可能完全和當前系統的版本號碼完全一致。舉個例子，假如System.gc()調用了本地庫glic6.0.2.so
那麼在當前系統上沒有這個版本的庫或沒有這個版本的庫的鏈結，那麼gc()方法肯定不能正確工作。
當然sun在發布的時候可能會把這個本地庫打包在JDK發行包中，但glic6.0.2.so中又調用了其它庫，如
subglic6.0.21.so，即使系統中存在完全相同的glic6.0.2.so，但你無法確認它調用的庫又完全符合，
事實上這幾乎是不可能完全符合的。

正是這樣本地庫版本號碼的不一致，才使得需要調用本地庫的JVM底層功能不能正確工作，所以清除，
退出進程等工作就可能無法完成，產生了java defunct。

知道了問題的原因，就能從多方面解決了。如果我們的JDK的src版進行編譯安裝而不是用SUN提供好的
本地庫，當然不會存在上面的問題，但現在好象已經不提供src編譯安裝的發布包了，所以指定核心版本
號，以便使它和JDK發布時使用的版本相一致，可以基本解決java defunct。

假如你不知道當前JDK的本地庫是基於什麼核心版本號碼發布的，一般來說，應該提供系統當前的核心版本號碼：

在Linux下，先查看當前的核心版本：
uname -r
2.4.21-4.EL
把主要版本號COPY下來，調用：
LD_ASSUME_KERNEL=2.4.21-4
export LD_ASSUME_KERNEL

如果你知道某個版本的JDK中的本地庫是基於某個核心版本發而布的那你可以直接指定LD_ASSUME_KERNEL為
這個版本，這樣會獲得最大的一致性