RUNNABLE Thread.State但在Object.wait（）中

Question

I have extracted a JStack of my container process and got the threads running there with the following distribution grouped by Thread.state :

count    thread state
   67    RUNNABLE
    1    TIMED_WAITING (on object monitor)
    8    TIMED_WAITING (parking)
    4    TIMED_WAITING (sleeping)
    3    WAITING (on object monitor)
   17    WAITING (parking)

For the runnable threads I have the following description:

"http-bio-8080-exec-55" daemon prio=10 tid=0x000000002cbab300 nid=0x642b in Object.wait() [0x00002ab37ad11000]
   java.lang.Thread.State: RUNNABLE
    at com.mysema.query.jpa.impl.JPAQuery.<init>(JPAQuery.java:44)
    at net.mbppcb.cube.repository.TransactionDaoImpl.findByBusinessId(TransactionDaoImpl.java:73)
    at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
    at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:155)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
    at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
    ...

The number of threads in RUNNABLE state as shown above raises with the time and it seems to be hanging. If they suppose to be blocked, shouldn't they be on state BLOCKED? Or should they be on WAITING state? Is strange to have RUNNABLE threads but in Object.wait() isn't it?

Update 1

I can see in the documentation:

A thread in the runnable state is executing in the Java virtual machine but it may be waiting for other resources from the operating system such as processor.

How can I figure out what is the thread waiting for?

Answer 1

This seems like a class initialization deadlock .

JPAQuery constructor is waiting for the initialization of a dependent class, probably JPAProvider :

    public JPAQuery(EntityManager em) {
        super(em, JPAProvider.getTemplates(em), new DefaultQueryMetadata());
    }

Such deadlocks may be caused by a typical bug when a subclass is referenced from a static initializer. If you share the details of other thread stacks, we'll likely find out which thread holds the class lock.

Why is the thread in RUNNABLE state then?

Well, it's a confusion inside HotSpot JVM. The class initialization procedure is implemented in VM runtime, not in Java land, and the class lock is grabbed natively. Seems to be a reason why a thread state has not been changed, but I guess this behavior should be fixed in JVM as well.

Answer 2

The Oracle Thread.State documentation specifies that a thread in the blocked state is waiting for a monitor lock to enter a synchronized block/method or reenter a synchronized block/method after calling. It looks like none of the threads in blocking mode.

Answer 3

If all the Runnable threads are apparently blocked in database operations, I would suggest using database monitoring/diagnostic tools to explore the reason. After that, possibly investigating your database code to find problems such as uncommitted transactions, mishandled exceptions leading to unclosed resources.

Java thread dumps have probably given you all the information they can at this point - a pointer for where to start looking next.

Answer 4

"The number of threads in RUNNABLE state as shown above raises with the time and it seems to be hanging."

The number of RUNNABLES would rise depending upon the number of threads executing the method "com.mysema.query.jpa.impl.JPAQuery." at the time this thread dump was taken. This method is actually the constructor of JPAQuery class - denoted by "init" . You would probably need to investigate the code in the constructor and the subsequent calls to the JPA implementation.

Answer 5

The Object.wait() merely calls Object.wait(0) (zero for no timeout). The implementation of Object.wait(long) is:

public final native void wait(long timeout) throws InterruptedException;

All threads that are in a native frame are RUNNABLE , as the JVM does not know (does not "manage", hence it is a "native" frame) the state of the call.