When to Synchronize Code

[Bijaysadhok]

The most difficult aspect of the synchronized keyword is deciding when to use it. You pay a performance penalty for using synchronized methods. The Java 2 platform brings some new internal algorithms to the JVM to improve performance of multithreaded programs.

[KevinWorkman]

I moved this to the Threads forum.

Do you have a question?

[nambill]

He doesn't have any question, he just wanted to point out a statement regarding synchronized keyword. In fact, performance is not considered when using synchronized keyword, since the difference is very little compared to non-synchronized. The important of using synchronized code is to prevent state of an object from being modified by multiple threads at a same time which may cause unpredictable result.

[KevinWorkman]

No, this was spam, copied and pasted from somewhere without any actual meaning- notice that he's talking about Java 2, which is ancient. He has since been banned.

Also, the performance penalty for synchronization is not necessarily non-trivial. This is one of the reasons people usually prefer ArrayList over Vector- Vector is synchronized, which introduces an unnecessary performance penalty in cases where synchronization is not needed, which is usually the case.

[Bob_Sadarka]

Hi Kevin,

Sorry I didn't notice that he is 'banned'. Synchronization is not performance penalty anymore, see this.

Also, thread-safe should be considered over performance. It's not good to sacrifice safety for a little performance.

[KevinWorkman]

Hi Kevin,Synchronization is not performance penalty anymore, see this.

Also, thread-safe should be considered over performance. It's not good to sacrifice safety for a little performance.

As that article points out, synchronization introduces a constant amount of overhead. If you don't need it, why introduce the overhead? Also, maintainability should be considered over unnecessary "thread safety" which is a non-issue in many programs that don't use multi-threading.

[helloworld922]

Adding synchronization does slow down your code. Every time the program encounters a synchronized section the program must acquire a lock for the object being synchronized. This is an expensive operation for short blocks which are run many times, but if it is necessary then you need it and had better add a synchronized section, or figure out a better way to make your code work as desired. I have seen sections of code where removing the unnecessary synchronized blocks has dramatically increased performance an order of magnitude, and other times where an unnecessary synchronized block has a negligible effect on performance.

Also, adding synchronization everywhere you can does not always increase thread safety, or produce the desired results.

ex.:

    private SomeType a, b;
 
    public void doIt1()
    {
        synchronized(a)
        {
            synchronized(b)
            {
                // do something with a and b
            }
        }
    }
 
    public void doIt2()
    {
        synchronized(b)
        {
            synchronized(a)
            {
                // do something with a and b
            }
        }
    }
}

This type of code can produce deadlocks if doIt1 and doIt2 are called simultaneously. This is a somewhat contrived example, but there are more elaborate pieces of code which can run into this issue when using synchronized naively. This is a block-level example, but method-level synchronized blocks are not necessarily immune to deadlocks.

The take-away:
If you don't need the synchronized section, don't use it (applies to any other locking mechanism, too). It's always possible for someone to add a specially tailored external locking mechanism to their application, but it's difficult/impossible for them to modify or remove internal locking.

[Bob_Sadarka]

So we should use synchronization where it requires. That's what I'd like to point out.

[helloworld922]

True, you should use synchronize when required. However, don't blindly believe that simply adding synchronized methods/blocks will solve all of your multi-threading problems, or is even a good solution if it works. One of the key goals of multi-threading is to offer a performance gain over single thread applications, and if you're unable to deliver that you should consider if multi-threading is the way to go for your particular application.

[Bob_Sadarka]

Yes, man. Especially in desktop apps which have GUI and background tasks running together.

[Json]

Personally I consider the synchronized keyword a smell and in any projects I manage nowadays I ask the developers to consult another developer for advice if they think that synchronized is needed. Usually in most cases you do not need to use synchronized but when you do it can be very tricky to get it right.

Having threading issues once you've gone live with a product is a proper pain, very difficult to track down.

If you really do think you need to use synchronized try and not use it on the actual method itself but rather around the code or particular method call that needs it. Also consider using the Lock interface, it might be more appropriate.

My conclusion of the past years have been that if you think you need to use synchronized you've probably made a design error along the way somewhere.

[Bob_Sadarka]

My conclusion of the past years have been that if you think you need to use synchronized you've probably made a design error along the way somewhere.

Oops! the synchronized keyword is useless? who invented it for what?

[KevinWorkman]

Oops! the synchronized keyword is useless? who invented it for what?

Nobody said it was useless, just misused. Nine times out of ten, if somebody is using it, they've likely backed themselves into a corner with their design or are simply misunderstanding how things are supposed to work. I would also put active rendering in this category.