Java defunct causes and solutions

Troubleshoot the causes and solutions of Java defunct:

In many cases, after we start the Java process, if we exit this Java process, we can still see the process in the system process.
This situation generally appears in the Unix/linux system, for the win platform appears less.

This process is on the UNIX platform and you can't kill it even if you kill it, but it still takes up system resources and becomes the real zombie.

The reason for the result:
When we downloaded the JDK, we could download it to the JDK's SRC and compile it ourselves, and now the official website could not find it on its own.
The JDK package, downloaded back to the JDK are release packages, we can imagine, regardless of sun in the release of the JDK to consider how perfect, local
Libraries are not completely consistent with the current system version number. For example, if System.GC () calls the local library glic6.0.2.so
Then the GC () method certainly does not work correctly on the current system without this version of the library or the link for this version of the library.
Of course, Sun May pack the local library in the JDK release package when it is released, but other libraries are called in the glic6.0.2.so, such as
Subglic6.0.21.so, even though there is exactly the same glic6.0.2.so in the system, you cannot confirm that the library it calls is exactly the same.
In fact, it's almost impossible to match exactly.

It is in this way that the local library version number is inconsistent so that the underlying functionality of the JVM that needs to invoke the local library does not work correctly, so clear,
Work such as exiting the process may not be completed, resulting in Java defunct.

Knowing the cause of the problem can be solved in many ways. If the SRC version of our JDK is compiled and installed instead of Sun-supplied
The local library, of course, does not exist above the problem, but now seems to have not provided the SRC compilation installation of the release package, so specify the kernel version
, so that it is consistent with the version used by JDK when it is released, and can basically solve the Java defunct.

If you do not know what kernel version the current JDK's local library is based on, in general, you should supply the current kernel version number of the system:

Under Linux, view the current kernel version first:
Uname-r
2.4.21-4.el
Copy the major version down and call:
Ld_assume_kernel=2.4.21-4
Export Ld_assume_kernel

If you know that a local library in a version of JDK is based on a kernel version, you can simply specify Ld_assume_kernel as
This version, which will achieve maximum consistency