java defunct产生的原因和解决办法
类别: JAVA教程
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为
这个版本,这样会获得最大的一致性
在很多时候,我们启动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为
这个版本,这样会获得最大的一致性
- 上一篇: JAVA 树中 按最长路径行驶
- 下一篇: Java Web Framework综述
-= 资 源 教 程 =-
文 章 搜 索