deadlock on synchronized ( String intern())

Question

I user sun jdk 1.5 ThreadPoolExecutor( 24, 24,60,TimeUnit.SECONDS, new LinkedBlockingQueue()). soemtime I use jdb tool to find the status of all threads in thread pool are " waiting in a monitor", the code is :

    String key = getKey(dt.getPrefix(), id);
    synchronized (key.intern()) {      ----->

Is there a problem in "synchronized (key.intern()) " ?

---

I get following informatnio using jdb tool, the status of 24 threads is "waiting in a monitor", it means 24 threads are deadlock at "key.intern()".

(java.lang.Thread)0x28 pool-3-thread-2 waiting in a monitor

(java.lang.Thread)0x27 pool-3-thread-3 waiting in a monitor

(java.lang.Thread)0x1b pool-3-thread-4 waiting in a monitor

(java.lang.Thread)0x1a pool-3-thread-5 waiting in a monitor

(java.lang.Thread)0x19 pool-3-thread-6 waiting in a monitor

(java.lang.Thread)0x18 pool-3-thread-7 waiting in a monitor

(java.lang.Thread)0x17 pool-3-thread-8 waiting in a monitor ...

so the result is : in multi-threads environment, Sting intern() method may be deadlock, ok ?

Solution 1

I posted a related question to this once that you might want to take a look at: Problem with synchronizing on String objects?

What I learned was: using intern'ed Strings for synchronization is a bad practice.

Solution 2

Quite. The problem is that key.intern() isn’t really that unique because it’s returning a string from a pool. String.intern() might return the same object even when used on different objects. Try using key itself or a different object altogether.

Solution 3

The code is almost certainly trying to synchronize actions that affect the same key. So it's calling intern() to ensure that the same key gets mapped to the same object, and therefore is valid as an object for synchronization.

The problem, if you're running into a bottleneck there (it's not a deadlock) is that you have too many operations coming in at the same time using the same key.

Rethink what needs to be synchronized.

Solution 4

There is not enough code here to tell what is going wrong. It could be a bottleneck as has been mentioned, but at least one thread should be running (with fairly heavy CPU usage) for that to happen, or a thread that has the lock is put to sleep without releasing the lock.

A deadlock is another possibility but that would require synchronization on two separate locks on multiple threads, and you have shown only one lock object here.

It is really impossible to determine without more information.

Solution 5

If you need to synchronize on a String, don't use a String instance as the mutex (interned or not). A string can be used to create a good mutex object, though: synchronizing on an ID.

View more solutions

Comments

[Miserable Variable]

How did you figure out he was talking about bottleneck?

[Miserable Variable]

What is wrong with using String.intern() as lock? I have myself used it successfully

[Bombe]

Of course it’s possible to use a String as a lock. However, for exactly the reasons mentioned in the answer it is seldom “good” (whatever that means) to do so.

[Miserable Variable]

Not sure I understand what is bad about it. That is causes deadlock? Or that it is a bottleneck? I don't think either is true.

[Bombe]

The point is that completely unrelated code can occupy “your” lock because it happens to use String.intern(), too—which results in the same object being used as the lock.

[kdgregory]

the definition of a deadlock is that two (or more) threads are waiting for resources owned by the other(s). This implies two synchronized blocks (or a loop). The code shown, while it could be in a loop, seems to be a pretty straightforward critical-section gate.

[Guillaume Coté]

It would be help full if you detail why it is a bad practice.

[Guillaume Coté]

Why would it cause the problem? I think the fact that the method is native or not has no impact, it occur before the synchronization starts.

[matt b]

doesn't the linked question answer that? when running JMeter tests against the webapp to simulate the expected load, I saw the used heap size grow to almost 1GB in just under 20 minutes.

[Guillaume Coté]

It would be a better answer if you quickly explain why in the answer instead of letting people read a long question.