views:

2119

answers:

8

In Java, the idiomatic way to declare critical sections in the code is the following:

private void doSomething() {
  // thread-safe code
  synchronized(this) {
    // thread-unsafe code
  }
  // thread-safe code
}

Almost all blocks synchronize on this, but is there a particular reason for this? Are there other possibilities? Are there any best practices on what object to synchronize on? (such as private instances of Object?)

+14  A: 

I try to avoid synchronizing on this because that would allow everybody from the outside who had a reference to that object to block my synchronization. Instead, I create a local synchronization object:

public class Foo {
    private final Object syncObject = new Object();
    …
}

Now I can use that object for synchronization without fear of anybody “stealing” the lock.

Bombe
+1 this is what I do too. Don't use strings though as String references aren't truly localized unless you're careful.
cletus
And who would try to "block your synchronization" on your object(s) in such a way that synchronizing on this would become dangerous, unpractical or unusable?
eljenso
@eljenso, who knows? Anybody with a reference might. :)
Bombe
Do make stack traces more readable, you might want to give the class of the locked object a name that shows which lock it is: `private static class Lock { }; private final Object lock = new Lock();`.
Tom Hawtin - tackline
@eljenso, I think it would be less likely the result of some malicious code and more likely a bug that would cause that issue
matt b
If you have bugs in your program, then debug. I am very skeptical of the fact that avoiding synchronized(this) will help you if you already don't have a real clue of what's going on in your multi-threaded program.
eljenso
@eljenso - I concur. No reasonable argument as to why to do this. If you have a greedy thread hogging your resources, solve the design problem.
Yuval A
@eljenso - I concu. Locking on "this" can allow an external caller to "atomicize" multiple method calls, which can be invaluable; consider iterating a synchronized collection; or the pain it is that PrintWriters using a private lock - ever tried writing a stack trace without interruption?
Software Monkey
Another problem with locking on 'this' blindly is that you could have several methods contending on the same lock that logically do not need to be mutually exclusive.
sk
+2  A: 

You'll want to synchronize on an object that can serve as a Mutex. If the current instance (the this reference) is suitable (not a Singleton, for instance), you may use it, as in Java any Object may serve as the Mutex.

In other occasions, you may want to share a Mutex between several classes, if instances of these classes may all need access to the same resources.

It depends a lot on the environment you're working in and the type of system you're building. In most Java EE applications I've seen, there's actually no real need for synchronization...

Electric Monk
+13  A: 

First, note that the following code snippets are identical.

public void foo() {
    synchronized (this) {
        // do something thread-safe
    }
}

and:

public synchronized void foo() {
    // do something thread-safe
}

do exactly the same thing. No preference for either one of them except for code readability and style.

When you do synchronize methods or blocks of code, it's important to know why you are doing such a thing, and what object exactly you are locking, and for what purpose.

Also note that there are situations in which you will want to client-side synchronize blocks of code in which the monitor you are asking for (i.e. the synchronized object) is not necessarily this, like in this example :

Vector v = getSomeGlobalVector();
synchronized (v) {
    // some thread-safe operation on the vector
}

I suggest you get more knowledge about concurrent programming, it will serve you a great deal once you know exactly what's happening behind the scenes. You should check out Concurrent Programming in Java, a great book on the subject. If you want a quick dive-in to the subject, check out Java Concurrency @ Sun

Yuval A
The code snippets LOGICALLY do the same thing, but they compile to different bytecode!!
Neil Coffey
Being very lazy and not trying it myself, you might want to explain the difference. Also, "different" is not really an issue here. If they are "equivalent", then everybody's happy.
eljenso
They are *not* equivalent. See http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Jason Day
@jason I never stated they were equivalent, although I admit that I thought they were. Still, I fail to see what DCL has to do with all this. Can you point out the relevant portion of the document. Still being lazy :)
eljenso
@Jason - can you please point to the exact location explaining your statement? I don't see the connection in the link you posted, sorry.
Yuval A
The double-checked locking code uses explicit "synchronized (this)" because it needs to do extra stuff before or after the sync. If you have nothing to do before or after, then they're really the same.
Rob Kennedy
DCL is relevant in that it points out that the compiler and/or JMM may do unexpected things. The two code snippets, as posted, do (essentially) the same thing, albeit with different bytecode. Naively adding code before or after the synchronized block (as in the OP) may not be thread-safe.
Jason Day
@jason Pointing to a document about DCL because "it points out that the compiler or JMM may do unexpected things" is overkill and not really to the point. You must specify WHY they are not equivalent. The majority of people agree that they are equivalent: http://stackoverflow.com/questions/417285
eljenso
Note that a syncronized method is often not the best option, since we hold a lock the whole time the method runs. If it contains timeconsuming but thread-safe parts, and a not so time consuming thread-unsafe part, a synchronized method is very wrong.
hstoerr
+1  A: 

Synchronization in Java often involves synchronizing operations on the same instance. Synchronizing on this then is very idiomatic since this is a shared reference that is automatically available between different instance methods (or sections of) in a class.

Using another reference specifically for locking, by declaring and initializing a private field Object lock = new Object() for example, is something I never needed or used. I think it is only useful when you need external synchronization on two or more unsynchronized resources inside an object, although I would always try to refactor such a situation into a simpler form.

Anyway, implicit (synchronized method) or explicit synchronized(this) is used a lot, also in the Java libraries. It is a good idiom and, if applicable, should always be your first choice.

eljenso
+1  A: 

Just to highlight that there are also ReadWriteLocks available in Java, found as java.util.concurrent.locks.ReadWriteLock.

In most of my usage, I seperate my locking as 'for reading' and 'for updates'. If you simply use a synchronized keyword, all reads to the same method/code block will be 'queued'. Only one thread can access the block at one time.

In most cases, you never have to worry about concurrency issues if you are simply doing reading. It is when you are doing writing that you worry about concurrent updates (resulting in lost of data), or reading during a write (partial updates), that you have to worry about.

Therefore a read/write lock makes more sense to me during multi-threaded programming.

Kent Lai
+4  A: 

As earlier answerers have noted, it is best practice to synchronize on an object of limited scope (in other words, pick the most restrictive scope you can get away with, and use that.) In particular, synchronizing on this is a bad idea, unless you intend to allow the users of your class to gain the lock.

A particularly ugly case arises, though, if you choose to synchronize on a java.lang.String. Strings can be (and in practice almost always are) interned. That means that each string of equal content - in the ENTIRE JVM - turns out to be the same string behind the scenes. That means that if you synchronize on any String, another (completely disparate) code section that also locks on a String with the same content, will actually lock your code as well.

I was once troubleshooting a deadlock in a production system and (very painfully) tracked the deadlock to two completely disparate open source packages that each synchronized on an instance of String whose contents were both "LOCK".

Jared
+1  A: 

Personally, I think the answers which insist that it is never or only rarely correct to sync on this are misguided. I think it depends on your API. If you class is a threadsafe implementation and you so document it, then you should use this. If the synchronization is not to make the class as a whole threadsafe in the invocation of it's public methods, then you should use a private internal object. Reusable library components often fall into the former category - you must think carefully before you disallow the user to wrap your API in external synchronization.

In the former case, using this allows multiple methods to be invoked in an atomic manner. One example is PrintWriter, where you may want to output multiple lines (say a stack trace to the console/logger) and guarantee they appear together - in this case the fact that it hides the sync object internally is a real pain. Another such example are the synchronized collection wrappers - there you must synchronize on the collection object itself in order to iterate; since iteration consists of multiple method invocations you cannot protect it totally internally.

In the latter case, I use a plain object:

private Object mutex=new Object();

However, having seen many JVM dumps and stack traces that say a lock is "an instance of java.lang.Object()" I have to say that using an inner class might often be more helpful, as others have suggested.

Anyway, that's my two bits worth.

Edit: One other thing, when synchronizing on this I prefer to sync the methods, and keep the methods very granular. I think it's clearer and more concise.

Software Monkey
Locking against a java.lang.String is a BAD idea - as Strings get interned. The result is that other completely disparate code could end up (unintentionally) locking on your lock. Locking on an inner class whose name is descriptive is perfectly reasonable. +1 if that suggestion gets edited out.
Jared
@Jared: Note that I specified new String("xxx"), not just "xxx". I am well aware of the dangers of interned strings.
Software Monkey
There's a difference between "synchronize on the object itself" and "synchronize on a reference exposed explicitly for the purpose of synchronization". If you need multiple clients to synchronize, then expose a reference for them to use. That makes it much more obvious what's going on. Still no need to lock on "this".
Jon Skeet
A: 

On what you synchronize depends on what other threads that might potentially get into conflict with this method call can synchronize.

If this is an object that is used by only one thread and we are accessing a mutable object which is shared between threads, a good candidate is to synchronize over that object - synchronizing on this has no point since another thread that modifies that shared object might not even know this, but does know that object.

On the other hand synchronizing over this makes sense if many threads call methods of this object at the same time, for instance if we are in a singleton.

Note that a syncronized method is often not the best option, since we hold a lock the whole time the method runs. If it contains timeconsuming but thread safe parts, and a not so time consuming thread-unsafe part, synchronizing over the method is very wrong.

hstoerr