Causes and Solutions of Java defunct

Java defunct causes and solutions:

In many cases, if we exit the Java Process after starting the Java Process, we can still see this process in the system process.
This situation usually occurs in Unix/Linux systems, but rarely on win platforms.

On UNIX platforms, even if you can't kill the process number, it still occupies system resources and becomes a real "zombie ".

Cause:
Before we downloaded JDK, we could download it to the JDK's SRC and compile it by ourselves. We can't find it on the official website.
The downloaded JDK package is a release package. We can imagine that no matter how perfect sun is when releasing JDK
The database cannot be exactly the same as the version number of the current system. For example, if system. GC () calls the local library glic6.0.2.so
If the current system does not have a database of this version or the database of this version is not linked, the GC () method cannot work correctly.
Of course, sun may package the local library in the JDK release package at the time of release, but other libraries are called in glic6.0.2.so, such
Subglic6.0.21.so, even if there are identical glic6.0.2.so in the system, you cannot confirm that the library it calls matches completely,
In fact, this is almost impossible to fully match.

In this way, the version numbers of the local database are inconsistent so that the JVM underlying functions of the local database to be called cannot work correctly,
A Java defunct is generated.

Once you know the cause of the problem, you can solve it in many ways. If the JDK for src is compiled and installed instead of provided by Sun
The local library, of course, will not have the above problem, but now it seems that the SRC compilation and installation of the release package is not provided, so specify the kernel version
So that it is consistent with the version used when JDK is released, and Java defunct can be basically solved.

If you do not know the kernel version number of the local JDK library, the current kernel version number of the system should be provided:

In Linux, first check the current kernel version:
Uname-R
2.4.21-4.el
Copy the main version number and call:
Ld_assume_kernel = 2.4.21-4
Export ld_assume_kernel

If you know that the local library in a JDK version is released based on a specific kernel version, you can directly specify ld_assume_kernel
This version ensures maximum consistency.