I&#39;m confused in `join()` method used in Threads in Java. In the following code:

    // Using join() to wait for threads to finish.
    class NewThread implements Runnable {

        String name; // name of thread
        Thread t;

        NewThread(String threadname) {
            name = threadname;
            t = new Thread(this, name);
            System.out.println(&quot;New thread: &quot; + t);
            t.start(); // Start the thread
        }
    // This is the entry point for thread.

        public void run() {
            try {
                for (int i = 5; i &gt; 0; i--) {
                    System.out.println(name + &quot;: &quot; + i);
                    Thread.sleep(1000);
                }
            } catch (InterruptedException e) {
                System.out.println(name + &quot; interrupted.&quot;);
            }
            System.out.println(name + &quot; exiting.&quot;);
        }
    }

    class DemoJoin {

        public static void main(String args[]) {
            NewThread ob1 = new NewThread(&quot;One&quot;);
            NewThread ob2 = new NewThread(&quot;Two&quot;);
            NewThread ob3 = new NewThread(&quot;Three&quot;);
            System.out.println(&quot;Thread One is alive: &quot;
                    + ob1.t.isAlive());
            System.out.println(&quot;Thread Two is alive: &quot;
                    + ob2.t.isAlive());
            System.out.println(&quot;Thread Three is alive: &quot;
                    + ob3.t.isAlive());
    // wait for threads to finish
            try {
                System.out.println(&quot;Waiting for threads to finish.&quot;);
                ob1.t.join();
                ob2.t.join();
                ob3.t.join();
            } catch (InterruptedException e) {
                System.out.println(&quot;Main thread Interrupted&quot;);
            }
            System.out.println(&quot;Thread One is alive: &quot;
                    + ob1.t.isAlive());
            System.out.println(&quot;Thread Two is alive: &quot;
                    + ob2.t.isAlive());
            System.out.println(&quot;Thread Three is alive: &quot;
                    + ob3.t.isAlive());
            System.out.println(&quot;Main thread exiting.&quot;);
        }
    }

Sample output from this program is shown here:

    New thread: Thread[One,5,main]
    New thread: Thread[Two,5,main]
    New thread: Thread[Three,5,main]
    Thread One is alive: true
    Thread Two is alive: true
    Thread Three is alive: true
    Waiting for threads to finish.
    One: 5
    Two: 5
    Three: 5
    One: 4
    Two: 4
    Three: 4
    One: 3
    Two: 3
    Three: 3
    One: 2
    Two: 2
    Three: 2
    One: 1
    Two: 1
    Three: 1
    Two exiting.
    Three exiting.
    One exiting.
    Thread One is alive: false
    Thread Two is alive: false
    Thread Three is alive: false
    Main thread Exiting

In the above code :

1. I&#39;m not able to understand the flow of execution of the program, And when `ob1` is created then the constructor is called where  `t.start()` is written but still `run()` method is not executed rather `main()` method continues execution. So why is this happening?

2. `join()` method is used to wait until the thread on which it is called does not terminates, but here in output we see alternate outputs of the thread why??

And if the use of `join` is this then what is the use of `synchronized`??

I know I&#39;m missing a basic concept here, but I&#39;m not able to figure it out so please help.

Java Multithreading concept and join() method

I have a webapp that I am in the middle of doing some load/performance testing on, particularily on a feature where we expect a few hundred users to be accessing the same page and hitting refresh about every 10 seconds on this page. One area of improvement that we found we could make with this function was to cache the responses from the web service for some period of time, since the data is not changing.

After implementing this basic caching, in some further testing I found out that I didn&#39;t consider how concurrent threads could access the Cache at the same time. I found that within the matter of ~100ms, about 50 threads were trying to fetch the object from the Cache, finding that it had expired, hitting the web service to fetch the data, and then putting the object back in the cache.

The original code looked something like this:

    private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {

      final String key = &quot;Data-&quot; + email;
      SomeData[] data = (SomeData[]) StaticCache.get(key);

      if (data == null) {
          data = service.getSomeDataForEmail(email);

          StaticCache.set(key, data, CACHE_TIME);
      }
      else {
          logger.debug(&quot;getSomeDataForEmail: using cached object&quot;);
      }
    
	  return data;
    }


So, to make sure that only one thread was calling the web service when the object at `key` expired, I thought I needed to synchronize the Cache get/set operation, and it seemed like using the cache key would be a good candidate for an object to synchronize on (this way, calls to this method for email b@b.com would not be blocked by method calls to a@a.com).

I updated the method to look like this:

    private SomeData[] getSomeDataByEmail(WebServiceInterface service, String email) {

      
      SomeData[] data = null;
      final String key = &quot;Data-&quot; + email;
      
      synchronized(key) {      
        data =(SomeData[]) StaticCache.get(key);

        if (data == null) {
            data = service.getSomeDataForEmail(email);
            StaticCache.set(key, data, CACHE_TIME);
        }
        else {
          logger.debug(&quot;getSomeDataForEmail: using cached object&quot;);
        }
      }
    
	  return data;
    }

I also added logging lines for things like &quot;before synchronization block&quot;, &quot;inside synchronization block&quot;, &quot;about to leave synchronization block&quot;, and &quot;after synchronization block&quot;, so I could determine if I was effectively synchronizing the get/set operation.

However it doesn&#39;t seem like this has worked. My test logs have output like:

    (log output is &#39;threadname&#39; &#39;logger name&#39; &#39;message&#39;)  
    http-80-Processor253 jsp.view-page - getSomeDataForEmail: about to enter synchronization block  
    http-80-Processor253 jsp.view-page - getSomeDataForEmail: inside synchronization block  
    http-80-Processor253 cache.StaticCache - get: object at key [SomeData-test@test.com] has expired  
    http-80-Processor253 cache.StaticCache - get: key [SomeData-test@test.com] returning value [null]  
    http-80-Processor263 jsp.view-page - getSomeDataForEmail: about to enter synchronization block  
    http-80-Processor263 jsp.view-page - getSomeDataForEmail: inside synchronization block  
    http-80-Processor263 cache.StaticCache - get: object at key [SomeData-test@test.com] has expired  
    http-80-Processor263 cache.StaticCache - get: key [SomeData-test@test.com] returning value [null]  
    http-80-Processor131 jsp.view-page - getSomeDataForEmail: about to enter synchronization block  
    http-80-Processor131 jsp.view-page - getSomeDataForEmail: inside synchronization block  
    http-80-Processor131 cache.StaticCache - get: object at key [SomeData-test@test.com] has expired  
    http-80-Processor131 cache.StaticCache - get: key [SomeData-test@test.com] returning value [null]  
    http-80-Processor104 jsp.view-page - getSomeDataForEmail: inside synchronization block  
    http-80-Processor104 cache.StaticCache - get: object at key [SomeData-test@test.com] has expired  
    http-80-Processor104 cache.StaticCache - get: key [SomeData-test@test.com] returning value [null]  
    http-80-Processor252 jsp.view-page - getSomeDataForEmail: about to enter synchronization block  
    http-80-Processor283 jsp.view-page - getSomeDataForEmail: about to enter synchronization block  
    http-80-Processor2 jsp.view-page - getSomeDataForEmail: about to enter synchronization block  
    http-80-Processor2 jsp.view-page - getSomeDataForEmail: inside synchronization block  

I wanted to see only one thread at a time entering/exiting the synchronization block around the get/set operations.

Is there an issue in synchronizing on String objects? I thought the cache-key would be a good choice as it is unique to the operation, and even though the `final String key` is declared within the method, I was thinking that each thread would be getting a reference to *the same object* and therefore would synchronization on this single object.

What am I doing wrong here?


**Update**: after looking further at the logs, it seems like methods with the same synchronization logic where the key is always the same, such as 



    final String key = &quot;blah&quot;;
    ...
    synchronized(key) { ...

do not exhibit the same concurrency problem - only one thread at a time is entering the block.

**Update 2**: Thanks to everyone for the help! I accepted the first answer about `intern()`ing Strings, which solved my initial problem - where multiple threads were entering synchronized blocks where I thought they shouldn&#39;t, because the `key`&#39;s had the same value.

As others have pointed out, using `intern()` for such a purpose and synchronizing on those Strings does indeed turn out to be a bad idea - 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.

Currently I&#39;m using the simple solution of just synchronizing the entire method - but I **really** like the code samples provided by martinprobst and MBCook, but since I have about 7 similar `getData()` methods in this class currently (since it needs about 7 different pieces of data from a web service), I didn&#39;t want to add almost-duplicate logic about getting and releasing locks to each method. But this is definitely very, very valuable info for future usage. I think these are ultimately the correct answers on how best to make an operation like this thread-safe, and I&#39;d give out more votes to these answers if I could!





Synchronizing on String objects in Java

Also, does the object that is being set have to be thread safe in order to guarantee that we know what the state of the object stored in session is known.

Also, I was reading on the web that some suggest using:

    synchronized(session) {
      session.setAttribute(&quot;abc&quot;, &quot;abc&quot;);
    }

Is this a valid suggestion?


Is HttpSession thread safe, are set/get Attribute thread safe operations?

I know the difference between synchronized method and synchronized block but I am not sure about the synchronized block part.

Assuming I have this code

    class Test {
      private int x=0;
      private Object lockObject = new Object();

      public void incBlock() {
        synchronized(lockObject) {
          x++;
        }
        System.out.println(&quot;x=&quot;+x);
      }

      public void incThis() {  // same as synchronized method
        synchronized(this) {
          x++;
        }
        System.out.println(&quot;x=&quot;+x);
      }
    }

In this case what is the difference between using _lockObject_ and using _this_ as the lock? It seems to be the same to me..

When you decide to use synchronized block, how do you decide which object to be the lock?

What is the difference between synchronized on lockObject and using this as the lock?

I am still pretty new to the concept of threading, and try to understand more about it. Recently, I came across a blog post on [What Volatile Means in Java][1] by Jeremy Manson, where he writes: 

&gt; When one thread writes to a volatile variable, and another thread sees
&gt; that write, the first thread is telling the second about **all** of the
&gt; contents of memory up until it performed the write to that volatile
&gt; variable. [...] **all** of the memory contents seen by Thread 1, before
&gt; it wrote to `[volatile] ready`, must be visible to Thread 2, after it
&gt; reads the value `true` for `ready`. [emphasis added by myself]

Now, does that mean that all variables (volatile or not) held in Thread 1&#39;s memory at the time of the write to the volatile variable will become visible to Thread 2 after it reads that volatile variable? If so, ***is it possible to puzzle that statement together from the official Java documentation/Oracle sources? And from which version of Java onwards will this work?***

In particular, if all Threads share the following class variables:

    private String s = &quot;running&quot;;
    private volatile boolean b = false;

And Thread 1 executes the following first:

    s = &quot;done&quot;;
    b = true;

And Thread 2 then executes afterwards (after Thread 1 wrote to the volatile field):

    boolean flag = b; //read from volatile
    System.out.println(s);

Would this be guaranteed to print &quot;done&quot;?

***What would happen if instead of declaring `b` as `volatile` I put the write and read into a `synchronized` block?***

Additionally, in a discussion entitled &quot;[Are static variables shared between threads?][2]&quot;, @TREE [writes][3]:

&gt; Don&#39;t use volatile to protect more than one piece of shared state.

***Why?*** (Sorry; I can&#39;t comment yet on other questions, or I would have asked there...)

  [1]: http://jeremymanson.blogspot.co.uk/2008/11/what-volatile-means-in-java.html
  [2]: https://stackoverflow.com/questions/4934913/are-static-variables-shared-between-threads
  [3]: https://stackoverflow.com/questions/4934913/are-static-variables-shared-between-threads#comment5502155_4934966


Happens-before relationships with volatile fields and synchronized blocks in Java - and their impact on non-volatile variables?

I saw some examples in java where they do synchronization on a block of code to change some variable while that variable was declared volatile originally .. I saw that in an example of singleton class where they declared the unique instance as volatile and they sychronized the block that initializes that instance ... My question is why we declare it volatile while we synch on it, why we need to do both?? isn&#39;t one of them is sufficient for the other ??

    public class SomeClass {
        volatile static Object uniqueInstance = null;

        public static Object getInstance() {
            if (uniqueInstance == null) {
                synchronized (someClass.class) {
                    if (uniqueInstance == null) {
                        uniqueInstance = new SomeClass();
                    }
                }
            }
            return uniqueInstance;
        }
    }
thanks in advance.




why using volatile with synchronized block?

I am wondering at the difference between declaring a variable as `volatile` and always accessing the variable in a `synchronized(this)` block in Java?

According to this article http://www.javamex.com/tutorials/synchronization_volatile.shtml there is a lot to be said and there are many differences but also some similarities.

I am particularly interested in this piece of info:

&gt; ...
&gt;
- access to a volatile variable never has the potential to block: we&#39;re only ever doing a simple read or write, so unlike a synchronized block we will never hold on to any lock;
- because accessing a volatile variable never holds a lock, it is not suitable for cases where we want to **read-update-write** as an atomic operation (unless we&#39;re prepared to &quot;miss an update&quot;);

What do they mean by **read-update-write**? Isn&#39;t a write also an update or do they simply mean that the **update** is a write that depends on the read?

Most of all, when is it more suitable to declare variables `volatile` rather than access them through a `synchronized` block? Is it a good idea to use `volatile` for variables that depend on input? For instance, there is a variable called `render` that is read through the rendering loop and set by a keypress event?

Difference between volatile and synchronized in Java

Let&#39;s say I have a synchronized method on some class:

    abstract class Foo {
        public synchronized void foo() {  // synchronized!
            // ...
        };
    }

and I overrode it **without** using the synchronized modifier:

    class Bar extends Foo {
        @Override
        public void foo() {               // NOT synchronized!
            super.foo();
            // ...
        }
     }

I have a couple of specific question regarding this scenario:

 1. Will the overridden method be implicitly synchronized as well?
 2. If not, will the `super`-call be synchronized?
 3. If there is no `super`-call, will anything be synchronized?
 4. Is there a way to force an overriding method to use `synchronized` (I noticed that abstract method definitions or method definitions inside an interface don&#39;t allow the synchronized keyword)?

Overriding synchronized methods in Java

I have some questions regarding the usage and significance of the `synchronized` keyword. 

- What is the significance of the `synchronized` keyword?
- When should methods be `synchronized`?
- What does it mean programmatically and logically?



What does &#39;synchronized&#39; mean?

If I have 2 synchronized methods in the same class, but each accessing different variables, can 2 threads access those 2 methods at the same time? Does the lock occur on the object, or does it get as specific as the variables inside the synchronized method? 

Example:

    class X {

        private int a;
        private int b;

        public synchronized void addA(){
            a++;
        }

        public synchronized void addB(){
            b++;
        }

    }

Can 2 threads access the same instance of class X performing `x.addA(`) and `x.addB()` at the same time?

Java synchronized method lock on object, or method?

In Java 8, I can easily write: 

    interface Interface1 {
        default void method1() {
            synchronized (this) {
                // Something
            }
        }

        static void method2() {
            synchronized (Interface1.class) {
                // Something
            }
        }
    }

I will get the full synchronisation semantics that I can use also in classes. I cannot, however, use the `synchronized` modifier on method declarations:

    interface Interface2 {
        default synchronized void method1() {
            //  ^^^^^^^^^^^^ Modifier &#39;synchronized&#39; not allowed here
        }

        static synchronized void method2() {
            // ^^^^^^^^^^^^ Modifier &#39;synchronized&#39; not allowed here
        }
    }

Now, one can argue that the two interfaces behave the same way except that `Interface2` establishes a *contract* on `method1()` and on `method2()`, which is a bit stronger than what `Interface1` does. Of course, we might also argue that `default` implementations should not make any assumptions about concrete implementation state, or that such a keyword simply wouldn&#39;t pull its weight.

### Question:

What is the reason why the JSR-335 expert group decided not to support `synchronized` on interface methods?



What is the reason why “synchronized” is not allowed in Java 8 interface methods?

If I synchronized two methods on the same class, can they run simultaneously **on the same object**? For example:

    class A {
    	public synchronized void methodA() {
    		//method A
    	}
    
    	public synchronized void methodB() {
    		// method B
    	}
    }

I know that I can&#39;t run `methodA()` twice on same object in two different threads. same thing in `methodB()`.

But can I run `methodB()` on different thread while `methodA()` is still running? (same object)

If I synchronized two methods on the same class, can they run simultaneously?

The Java documentation says: 

&gt; It is not possible for two invocations of synchronized methods on the
&gt; same object to interleave.

What does this mean for a static method?  Since a static method has no associated object, will the synchronized keyword lock on the class, instead of the object?


Java synchronized static methods: lock on object or class

What does this java code mean? Will it gain lock on all objects of `MyClass`?

    synchronized(MyClass.class) {
       //is all objects of MyClass are thread-safe now ??
    }

And how the above code differs from this one:

    synchronized(this) {
       //is all objects of MyClass are thread-safe now ??
    }


Java Synchronized Block for .class

A warning is showing every time I synchronize on a non-final class field. Here is the code:  

    public class X  
    {  
       private Object o;  
         
       public void setO(Object o)  
       {  
         this.o = o;  
       }  
        
       public void x()  
       {  
         synchronized (o) // synchronization on a non-final field  
         {  
         }  
       }  
     } 

so I changed the coding in the following way:
  

     public class X  
     {  
       
       private final Object o;       
       public X()
       {  
         o = new Object();  
       }  
        
       public void x()  
       {  
         synchronized (o)
         {  
         }  
       }  
     }  

I am not sure the above code is the proper way to synchronize on a non-final class field. How can I synchronize a non final field? 

Synchronization of non-final field

Can any one tell me the advantage of synchronized method over synchronized block with an example?

Is there an advantage to use a Synchronized Method instead of a Synchronized Block?

Whenever a question pops up on SO about Java synchronization, some people are very eager to point out that `synchronized(this)` should be avoided. Instead, they claim, a lock on a private reference is to be preferred.

Some of the given reasons are:

 - [some *evil code* may steal your lock][1] (very popular this one, also has an &quot;accidentally&quot; variant)
 - [all synchronized methods within the same class use the exact same lock, which reduces throughput][2]
 - [you are (unnecessarily) exposing too much information][3]

Other people, including me, argue that `synchronized(this)` is an idiom that is used a lot (also in Java libraries), is safe and well understood. It should not be avoided because you have a bug and you don&#39;t have a clue of what is going on in your multithreaded program. In other words: if it is applicable, then use it.

I am interested in seeing some real-world examples (no foobar stuff) where avoiding a lock on `this` is preferable when `synchronized(this)` would also do the job.

Therefore: **should you always avoid `synchronized(this)` and replace it with a lock on a private reference?**  

---

Some further info (updated as answers are given):

 - we are talking about instance synchronization
 - both implicit (`synchronized` methods) and explicit form of `synchronized(this)` are considered
 - if you quote Bloch or other authorities on the subject, don&#39;t leave out the parts you don&#39;t like (e.g. Effective Java, item on Thread Safety: *Typically it is the lock on the instance itself, but there are exceptions.)*
 - if you need granularity in your locking other than `synchronized(this)` provides, then `synchronized(this)` is not applicable so that&#39;s not the issue

  [1]: https://stackoverflow.com/questions/416183/in-java-critical-sections-what-should-i-synchronize-on#416198
  [2]: https://stackoverflow.com/questions/309631/what-cases-require-synchronized-method-access-in-java#309677
  [3]: https://stackoverflow.com/questions/439302/allowing-a-method-to-lock-its-parent-object-in-java#439317

Avoid synchronized(this) in Java?

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`?)

In Java critical sections, what should I synchronize on?

Are there any unclear side effects to throwing an exception from within a synchronized clause?
What happens to the lock? 

    private void doSomething() throws Exception {...}
    
    synchronized (lock) {   
        doSomething();       
    }


Side effects of throwing an exception inside a synchronized clause?

    private double value;

    public synchronized void setValue(double value) {
        this.value = value;
    }
    public double getValue() {
        return this.value;
    }

In the above example is there any point in making the getter synchronized?

Should getters and setters be synchronized?

According to [the Java Language Specification][1], constructors cannot be marked synchronized because other threads cannot see the object being created until the thread creating it has finished it.  This seems a bit odd, because I can indeed have another thread view the object while it&#39;s being constructed:

    public class Test {
        public Test() {
           final Test me = this;
           new Thread() {
               @Override
               public void run() {
                   // ... Reference &#39;me,&#39; the object being constructed
               }
           }.start();
        }
    }

I know that this is a pretty contrived example, but it seems in theory that someone could come up with a more realistic case where marking the constructor synchronized would be legitimate in order to prevent races with threads like this one.

My question is this: is there a reason that Java would specifically disallow the synchronized modifier on a constructor?  Perhaps my above example is flawed, or perhaps there really is no reason and it&#39;s an arbitrary design decision.  In either case, I&#39;m really curious and would love to know the answer.


  [1]: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.8.3

Why can&#39;t Java constructors be synchronized?

this is a passage from JavaDoc regarding `ConcurrentHashMap`. It says retrieval operations generally do not block, so may overlap with update operations. Does this mean the `get()` method is not thread safe?


&gt; &quot;However, even though all operations are thread-safe, retrieval
&gt; operations do not entail locking, and there is not any support for
&gt; locking the entire table in a way that prevents all access. This class
&gt; is fully interoperable with Hashtable in programs that rely on its
&gt; thread safety but not on its synchronization details.
&gt; 
&gt; Retrieval operations (including get) generally do not block, so may
&gt; overlap with update operations (including put and remove). Retrievals
&gt; reflect the results of the most recently completed update operations
&gt; holding upon their onset.&quot;

All Synchronized Solutions on Gang of Coders

Total of 22 Synchronized Solutions