The reasons and solutions generated by Java Defunct:
In many cases, after we start the Java process, if you exit this Java process, you can still see this process in the system process.
This situation generally appears in the UNIX / Linux system, which is less in the Win platform.
This process is on UNIX platform, even if the Kill process number cannot kill it, it still takes up system resources to become a real "zombie".
Causes:
In the past, when we downloaded JDK, you can download to JDK's SRC and compile it yourself. Now you can't find yourself on the official website.
The JDK package translated, downloaded JDK is released, we can imagine, regardless of the SUN, think about how perfect, local
The library cannot be completely consistent with the version number of the current system. For example, if system.gc () calls the local library glic6.0.2.so
Then there is no link to this version of the library or without this version of the library on the current system, then the GC () method must not work correctly.
Of course, Sun may packed this local library in the JDK release package when the sun is released, but other libraries are called in Glic6.0.2.so.
Subglic6.0.21.so, even if there is exactly the same GLIC6.0.2.SO, you can't confirm that the library it calls is completely matched.
In fact, this is almost impossible to match.
It is the case where the locally library version number is inconsistent, so that the JVM underlying function that needs to call the local library cannot work correctly, so clear,
Work such as exiting the process may not be completed, generating Java Defunct.
If you know the cause of the problem, you can solve it from many ways. If our JDK's SRC version is compiled, it is good to provide SUN.
Local library, of course, there is no top problem, but now I have not provided a release package that I have not provided SRC compilation installation, so the core version is specified.
Number, in order to make the version used in JDK, can basically solve the Java Defunct.
If you don't know what the current JDK's local library is based on what kernel version number is released, in general, the current core version number should be provided:
Under Linux, first see the current kernel version:
Uname -R
2.4.21-4.el
Call the primary version number Copy, call:
LD_Assume_kernel = 2.4.21-4
Export ld_assume_kernel
If you know that the local library in a version of JDK is based on a kernel version, you can specify ld_assume_kernel directly
This version will get the biggest consistency.
