What does "locked" mean in a Java stack trace?

Question

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.

Overbid

Answer 1

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)

Regatta

Thanks. So this doesn't mean that the thread is idle or asleep, which is what I had assumed. I see a lot of threads like this in my Tomcat server. Is that a normal condition? – Overbid

@Frank LaRosa: Absolutely. At any given time, we have 10 to 100 threads in that state on our servers. The whole point of that thread is to wait until another server pokes it asking for information, and since you usually want to have the ability to process more than one request at a time (fulltext searches for instance), you will have multiple connectors available. – Regatta

But those threads aren't just spinning in a loop using CPU cycles while they're waiting for a connection, right? Assuming they aren't, what's causing them not to? Normally when I create a worker thread, it spends most of its time in the WAITING state, until some other thread notifies it. In this case, the threads are all listed as RUNNABLE. – Overbid

@Frank LaRosa: I believe the way that socket threads work in Java is that they are in some kind of midway state - they are essentially in a sleep state and are woken when something arrives to connect to them...but they aren't technically sleeping :) – Regatta

I often see 'wating on <somevalue>' and then later on in the trace 'locked <thesamesomevalue>', what does it means ? That the thread has a lock and it's waiting for a lock that it has created ? Does it sounds like a deadlock ? – Unharness

I'm not sure what you mean exactly, but a thread can and will re-lock an object it already owns the lock on without issue. If it is causing you problems, I suggest submitting your own question but if not, why worry? :) – Regatta

I am not having a particular issue, just trying to learn more. This is often seen within the finalizer thread in a thread dump. A lock statement followed by a waiting on, bot referred to the same <address>. So I was wondering how can a thread wait for itself, and yes there's space for a new question :-) – Unharness

@Leonardo: See javasanity.org/understandingthreaddumps, item #3 especially. – Regatta

Answer 2

From java 6 documentation:

An object monitor is locked when entering a synchronization block or method on that object.

Hedges

While true, not exactly very helpful or descriptive. – Regatta

Since when was documentation supposed to be helpful and descriptive? ;) – Rellia