RUNNABLE Thread.State but in 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.springf…

Accepted Answer

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.

RUNNABLE Thread.State but in Object.wait()

Solution

Problem