For example, this is a stack trace from a Tomcat server:
"RMI TCP Accept-0" daemon prio=10 tid=0x091a5800 nid=0x8f1 runnable [0x8b305000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
- locked <0x911d3c30> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:462)
at java.net.ServerSocket.accept(ServerSocket.java:430)
at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:34)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:369)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:341)
at java.lang.Thread.run(Thread.java:662)
My guess is that "locked" means the CPU is waiting on some sort of a lock. However, if that is the case, why is the thread's state listed as RUNNABLE rather than BLOCKED?
Thanks.
It means that this thread (RMI TCP Accept-0) has ownership of the object with hash code 0x911d3c30, in this case a java.net.SocksSocketImpl
. While this thread owns the lock, no other thread can have it, blocking them from entering this portion of code (often a function). See here for more info:
http://download.oracle.com/javase/tutorial/essential/concurrency/newlocks.html
Also, it is RUNNABLE because it is still running... If you notice that the locked
is not at the TOP of the stack but rather inside it, that means that it holds the lock and continued executing. The next thread to come by this section of code would be blocked by that lock.
EDIT Because this is too awkward to fit into a comment... If you see THIS, you are seeing a thread that is blocked. Note is says waiting to lock
"http-80-exec-113":
at com.airs.utilities.server.Entity.serializeZip64(Entity.java:6314)
- waiting to lock <0x00007fbefe44d5c8> (a java.lang.String)
at com.airs.utilities.server.Entity.serializeZip64(Entity.java:6300)