Java™ Developer Kit (JDK) Native Memory Leak Causes High CPU, Hang and/or Crash

Technote (FAQ)
Problem
In JDK 1.2.2 and 1.3.x, both GZIPOutputStream and DeflaterOutputStream allocate deflator objects that use very large chunks of native (non-Java heap) memory. Some applications that use these native chunks can accumulate, causing memory to leak. Programming best practices do NOT recommend this technique.

This problem might occur on any release of JDK 1.2.2 or 1.3.x. As of Dec 2001 (JDK 122 SR 14 and 131 SR 15), there was a fix put in for GZIPOutputStream. There is a patch available for DeflaterOutputStream upon request. However, a complete fix for both classes is not yet available.
Cause
The problem is from a memory leak in the GZipOutputStream and DeflaterOutputStream. This requires an updated JDK module from the IBM Java Technology Center (JTC). The JTC defect number for this fix is SOV,50944.
Solution
Symptoms:
  • CPU utilization higher than expected. Generally you see stepping (big jumps) in CPU utilization, say 25% to 50% then to 75%. Eventually the CPU utilization might peg at 100%.
  • Application server might hang with 100% CPU.
  • Application Server crashes.
  • A native memory leak can be observed by monitoring the process memory utilization. This is more evident on Unix® systems (particularly AIX). On Windows, the memory leak seems not to be noticed.
Details:

Both GZIPOutputStream and DeflaterOutputStream use Deflater objects. Deflator objects are small objects on the Java heap, but their native methods allocate large amounts of native storage as well. The native storage is released by the Deflater.end() method, which is called either by finalization of the Deflators or explicitly by the application code.

A fix was put into the JDK for GZIPOutputStream to end() its Deflator when it is closed. GZIPOutputStream constructor(s) allocate(s) a private Deflator, so it is reasonable to add the fix to end when the Deflator GZIPOutputStream is closed. However, DeflaterOutputStream can have a Deflator passed to one of its constructors, so it was not considered safe to automatically end the Deflator because the caller might want to reuse it. The patch mentioned above causes DeflaterOutputStream to automatically deallocate its deflator on close().

The problem is from a memory leak in the GZipOutputStream and DeflaterOutputStream. This requires an updated JDK module from the IBM Java Technology Center (JTC). The JTC defect number for this fix is SOV,50944. Any JDK that contains the bug fix for that defect will resolve this problem, assuming that it is compatible with the one you are presently using.












    Document Information

    Product categories: Software, Application Servers, Distribut, ed Application & Web Servers, WebSphere Application Server, Java SDK
    Operating system(s): Multi-Platform
    Software version: 3.5.4, 3.5.5, 3.5.6, 4.0.1, 4.0.2, 4.0.3
    Software edition: Edition Independent
    Reference #: 1054892
    IBM Group: Software Group
    Modified date: 2004-01-14