Question

I got a thread dump of one of my processes. It has a bunch of these threads. I guess they are keeping a bunch of memory so I am getting OOM.

"Thread-8264" prio=6 tid=0x4c94ac00 nid=0xf3c runnable [0x4fe7f000]
   java.lang.Thread.State: RUNNABLE
    at java.util.zip.Inflater.inflateBytes(Native Method)
    at java.util.zip.Inflater.inflate(Inflater.java:223)
    - locked <0x0c9bc640> (a java.util.zip.Inflater)
    at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:235)
    at com.my.ZipExtractorCommonsCompress.extract(ZipExtractorCommonsCompress.java:48)
    at com.my.CustomThreadedExtractorWrapper$ExtractionThread.run(CustomThreadedExtractorWrapper.java:151)

   Locked ownable synchronizers:
    - None

"Thread-8241" prio=6 tid=0x4c94a400 nid=0xb8c runnable [0x4faef000]
   java.lang.Thread.State: RUNNABLE
    at java.util.zip.Inflater.inflateBytes(Native Method)
    at java.util.zip.Inflater.inflate(Inflater.java:223)
    - locked <0x0c36b808> (a java.util.zip.Inflater)
    at org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:235)
    at com.my.ZipExtractorCommonsCompress.extract(ZipExtractorCommonsCompress.java:48)
    at com.my.CustomThreadedExtractorWrapper$ExtractionThread.run(CustomThreadedExtractorWrapper.java:151)

   Locked ownable synchronizers:
    - None

I am trying to find out how it arrived to this situation. CustomThreadedExtractorWrapper is a wrapper class that fires a thread to do some work (ExtractionThread, which uses ZipExtractorCommonsCompress to extract zip contents from a compressed stream). If the task is taking too long, ExtractionThread.interrupt() is called to cancel the operation.

I can see in my logs that the cancellation happened 25 times. And I see 21 of these threads in my dump. My questions:

1. What is the status of these threads? Alive and running? Blocked somehow?
2. They did not die with .interrupt() apparently? Is there a sure way to really kill a thread?
3. What does really mean ‘locked ‘ in the stack trace?

Line 223 in Inflater.java is:

public synchronized int inflate(byte[] b, int off, int len) {
    ...
    //return is line 223
    return inflateBytes(b, off, len);                          
}

Answer 1

“locked” means that they own a monitor; namely, the method is synchronized, and the thread dump shows the address of the instance on which synchronization is performed.

You can try to kill a thread with Thread.stop(), but the thread may resist, and it is inherently unsafe, deprecated, and very bad. Do not do it. Besides, I am not sure it works when the thread is in a native method, as is the case here.

Thread.interrupt() nudges the target thread. The thread will notice it the next time it either looks at the interrupt flag explicitly, or performs some potentially blocking operation (I/O, or wait()). The thread may catch the exception and ignore it.

Your threads are “runnable”: they are not blocked. Inflater.inflate() is not a blocking function anyway; it performs in-memory computations only. There may be a bug in the native implementation (Inflater.inflateBytes(), but that’s not very probable because this relies on Zlib, which is a very stable piece of code). More plausibly, one of the callers (e.g. your ZipExtractorCommonsCompress class) is stuck in a loop in which it asks the Zip extractor to process zero more bytes, and does not understand that it should wait for some more data before trying again.