java defunct產(chǎn)生的原因和解決辦法:

在很多時(shí)候,我們啟動(dòng)JAVA進(jìn)程后,假如退出這個(gè)JAVA進(jìn)程,在系統(tǒng)進(jìn)程中仍然可以看到這個(gè)進(jìn)程.
這種情況一般出現(xiàn)在UNIX/linux系統(tǒng),對(duì)于WIN平臺(tái)出現(xiàn)情況較少.

這個(gè)進(jìn)程在UNIX平臺(tái)上,你即使kill進(jìn)程號(hào)也不能殺掉它,但它仍然占用系統(tǒng)資源,成了真正的"僵尸"。

產(chǎn)生的原因：
以前我們下載JDK時(shí)，可以下載到JDK的SRC然后自己編譯，現(xiàn)在的官方網(wǎng)站上已經(jīng)找不到可以自己編
譯的JDK包，下載回來的JDK都是釋放包，我們可以想象，無論SUN在發(fā)布JDK時(shí)考慮得如何完美，本地
庫(kù)都不可能完全和當(dāng)前系統(tǒng)的版本號(hào)完全一致。舉個(gè)例子，假如System.gc()調(diào)用了本地庫(kù)glic6.0.2.so
那么在當(dāng)前系統(tǒng)上沒有這個(gè)版本的庫(kù)或沒有這個(gè)版本的庫(kù)的鏈結(jié)，那么gc()方法肯定不能正確工作。
當(dāng)然sun在發(fā)布的時(shí)候可能會(huì)把這個(gè)本地庫(kù)打包在JDK發(fā)行包中，但glic6.0.2.so中又調(diào)用了其它庫(kù)，如
subglic6.0.21.so，即使系統(tǒng)中存在完全相同的glic6.0.2.so，但你無法確認(rèn)它調(diào)用的庫(kù)又完全匹配，
事實(shí)上這幾乎是不可能完全匹配的。

正是這樣本地庫(kù)版本號(hào)的不一致，才使得需要調(diào)用本地庫(kù)的JVM底層功能不能正確工作，所以清除，
退出進(jìn)程等工作就可能無法完成，產(chǎn)生了java defunct。

知道了問題的原因，就能從多方面解決了。假如我們的JDK的src版進(jìn)行編譯安裝而不是用SUN提供好的
本地庫(kù)，當(dāng)然不會(huì)存在上面的問題，但現(xiàn)在好象已經(jīng)不提供src編譯安裝的發(fā)布包了，所以指定內(nèi)核版本
號(hào)，以便使它和JDK發(fā)布時(shí)使用的版本相一致，可以基本解決java defunct。

假如你不知道當(dāng)前JDK的本地庫(kù)是基于什么內(nèi)核版本號(hào)發(fā)布的，一般來說，應(yīng)該提供系統(tǒng)當(dāng)前的內(nèi)核版本號(hào)：

在Linux下，先查看當(dāng)前的內(nèi)核版本：
uname -r
2.4.21-4.EL
把主版本號(hào)COPY下來，調(diào)用：
LD_ASSUME_KERNEL=2.4.21-4
eXPort LD_ASSUME_KERNEL

假如你知道某個(gè)版本的JDK中的本地庫(kù)是基于某個(gè)內(nèi)核版本發(fā)而布的那你可以直接指定LD_ASSUME_KERNEL為
這個(gè)版本，這樣會(huì)獲得最大的一致性