Java Thread Problem - Synchronization

In its most general form, yes.

Objects that cannot be synchronized are not subject to.

Also, you can use separate monitors / locks for mutable instance variables (or groups) to help with liveliness. Just like syncing only the parts where the data changes, not the whole method.

synchronized methodName vs synchronized (object)

This is correct and this is one of the alternatives. I think it would be more efficient to synchronize access to this object and instead synchronize all its methods.

While the difference can be subtle, it would be helpful if you use the same object on the same thread

those. (using the synchronized keyword in the method)

class SomeClass {
    private int clickCount  = 0;

    public synchronized void click(){
        clickCount++;
    }
 }

      

        
        
        
      

    

When a class is defined like this, only one thread at a time can call the method click

.

What happens if this method is called too often in a single threaded application? You will spend extra time checking to see if this thread can acquire a lock on the object when not needed.

class Main {
    public static void main( String  [] args ) {
         SomeClass someObject = new SomeClass();
         for( int i = 0 ; i < Integer.MAX_VALUE ; i++ ) {
             someObject.click();
         }
    }
 }

      

        
        
        
      

    

In this case, the check to see if the thread can lock the object will be called unnecessarily Integer.MAX_VALUE

(2,147,483,647) times.

Therefore, deleting a synchronized keyword in this situation will be much faster.

So how would you do this in a multithreaded application?

You just sync the object:

synchronized ( someObject ) {
    someObject.click();
}

      

        
        
        
      

    

Vector vs ArrayList

As a side note, this use of (synchhonized methodName vs. syncrhonized (object)) is, by the way, one of the reasons why java.util.Vector

it is now replaced with java.util.ArrayList

. Many of the methods are Vector

synchronized.

Most of the time the list is used in a single threaded application or piece of code (i.e. the code inside jsp / servlets is executed in a single thread) and the extra synchronization of the Vector doesn't help performance.

The same happens when replacing Hashtable

withHashMap

Actually getters a needs to be synchronized as well, or fields need to be done volatile

. This is because when you get a value, you are probably interested in the most recent version of the value. You can see that synchronized

block semantics not only ensure that execution is atomic (for example, it ensures that only one thread executes that block at a time), but also visibility. This means that when a thread enters a block synchronized

, it invalidates its local cache, and when it exits, it dumps any variables that have changed back to main memory. volatile

variables have the same visibility semantics.

No. Even getters need to be in sync, unless they only have access to final fields. The reason is that, for example, when accessing a long value, there is a small change that another stream is currently writing and you are reading it, and only the first 4 bytes have been written while the other 4 bytes remain the old value.

Yes, it's right. All methods that modify data or access data that can be modified by another thread must be synchronized on the same monitor.

The easiest way is to mark the methods as synchronized. If these are lengthy methods, you may only want to sync those read / write parts. In this case, you define the monitor as well as wait () and notify ().

The simple answer is yes. If a class object will be shared by multiple threads, you need to keep the getters and setters in sync to prevent data inconsistency. If all threads will have a separate copy of the object, then there is no need to synchronize methods. If your instance methods are more than just set and retrieved, you should analyze the threat of threads waiting for the getter / setter to finish.