Difference between volatile and synchronized in Java

Question

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                  access to a volatile variable never has the potential to block  we 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 re prepared to  miss an update         What do they mean by read-update-write  Isn 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

User · Answer

volatile is a field modifier  while synchronized modifies code blocks and methods  So we can specify three variations of a simple accessor using those two keywords       int i1      int geti1    return i1        volatile int i2      int geti2    return i2        int i3      synchronized int geti3    return i3         geti1   accesses the value currently stored in i1 in the current thread    Threads can have local copies of variables  and the data does not have to be the same as the data held in other threads In particular  another thread may have updated i1 in it s thread  but the value in the current thread could be different from that updated value  In fact Java has the idea of a  main  memory  and this is the memory that holds the current  correct  value for variables  Threads can have their own copy of data for variables  and the thread copy can be different from the  main  memory  So in fact  it is possible for the  main  memory to have a value of 1 for i1  for thread1 to have a value of 2 for i1 and for thread2 to have a value of 3 for i1 if thread1 and thread2 have both updated i1 but those updated value has not yet been propagated to  main  memory or other threads       On the other hand  geti2   effectively accesses the value of i2 from  main  memory  A volatile variable is not allowed to have a local copy of a variable that is different from the value currently held in  main  memory  Effectively  a variable declared volatile must have it s data synchronized across all threads  so that whenever you access or update the variable in any thread  all other threads immediately see the same value  Generally volatile variables have a higher access and update overhead than  plain  variables  Generally threads are allowed to have their own copy of data is for better efficiency       There are two differences between volitile and synchronized       Firstly synchronized obtains and releases locks on monitors which can force only one thread at a time to execute a code block  That s the fairly well known aspect to synchronized  But synchronized also synchronizes memory  In fact synchronized synchronizes the whole of thread memory with  main  memory  So executing geti3   does the following          The thread acquires the lock on the monitor for object this     The thread memory flushes all its variables  i e  it has all of its variables effectively read from  main  memory     The code block is executed  in this case setting the return value to the current value of i3  which may have just been reset from  main  memory      Any changes to variables would normally now be written out to  main  memory  but for geti3   we have no changes     The thread releases the lock on the monitor for object this           So where volatile only synchronizes the value of one variable between thread memory and  main  memory  synchronized synchronizes the value of all variables between thread memory and  main  memory  and locks and releases a monitor to boot  Clearly synchronized is likely to have more overhead than volatile     http   javaexp blogspot com 2007 12 difference-between-volatile-and html

User · Answer

synchronized is method level block level access restriction modifier  It will make sure that one thread owns the lock for critical section  Only the thread which own a lock can enter synchronized block  If other threads are trying to access this critical section  they have to wait till current owner releases the lock    volatile is variable access modifier which forces all threads to get latest value of the variable from main memory  No locking is required to access volatile variables  All threads can access volatile variable value at same time    A good example to use volatile variable   Date variable   Assume that you have made Date variable volatile  All the threads  which access this variable always get latest data from main memory so that all threads show real  actual  Date value  You don t need different threads showing different time for same variable  All threads should show right Date value     Have a look at this article for better understanding of volatile concept    Lawrence Dol cleary explained your read-write-update query    Regarding your other queries     When is it more suitable to declare variables volatile than access them through synchronized     You have to use volatile if you think all threads should get actual value of the variable in real time like the example I have explained for Date variable       Is it a good idea to use volatile for variables that depend on input    Answer will be same as in first query    Refer to this article for better understanding

User · Answer

tl dr   There are 3 main issues with multithreading   1  Race Conditions  2  Caching   stale memory  3  Complier and CPU optimisations  volatile can solve 2  amp  3  but can t solve 1  synchronized explicit locks can solve 1  2  amp  3   Elaboration   1  Consider this thread unsafe code   x      While it may look like one operation  it s actually 3  reading the current value of x from memory  adding 1 to it  and saving it back to memory  If few threads try to do it at the same time  the result of the operation is undefined  If x originally was 1  after 2 threads operating the code it may be 2 and it may be 3  depending on which thread completed which part of the operation before control was transferred to the other thread  This is a form of race condition    Using synchronized on a block of code makes it atomic - meaning it make it as if the 3 operations happen at once  and there s no way for another thread to come in the middle and interfere  So if x was 1  and 2 threads try to preform x   we know in the end it will be equal to 3  So it solves the race condition problem    synchronized  this       x       no problem now     Marking x as volatile does not make x    atomic  so it doesn t solve this problem   2  In addition  threads have their own context - i e  they can cache values from main memory  That means that a few threads can have copies of a variable  but they operate on their working copy without sharing the new state of the variable among other threads    Consider that on one thread  x   10   And somewhat later  in another thread  x   20   The change in value of x might not appear in the first thread  because the other thread has saved the new value to its working memory  but hasn t copied it to the main memory  Or that it did copy it to the main memory  but the first thread hasn t updated its working copy  So if now the first thread checks if  x    20  the answer will be false    Marking a variable as volatile basically tells all threads to do read and write operations on main memory only  synchronized tells every thread to go update their value from main memory when they enter the block  and flush the result back to main memory when they exit the block    Note that unlike data races  stale memory is not so easy to  re produce  as flushes to main memory occur anyway    3  The complier and CPU can  without any form of synchronization between threads  treat all code as single threaded  Meaning it can look at some code  that is very meaningful in a multithreading aspect  and treat it as if it   s single threaded  where it   s not so meaningful  So it can look at a code and decide  in sake of optimisation  to reorder it  or even remove parts of it completely  if it doesn   t know that this code is designed to work on multiple threads     Consider the following code   boolean b   false  int x   10   void threadA         x   20      b   true     void threadB         if  b            System out println x             You would think that threadB could only print 20  or not print anything at all if threadB if-check is executed before setting b to true   as b is set to true only after x is set to 20  but the compiler CPU might decide to reorder threadA  in that case threadB could also print 10  Marking b as volatile ensures that it won   t be reordered  or discarded in certain cases   Which mean threadB could only print 20  or nothing at all   Marking the methods as syncrhonized will achieve the same result  Also marking a variable as volatile only ensures that it won   t get reordered  but everything before after it can still be reordered  so synchronization can be more suited in some scenarios   Note that before Java 5 New Memory Model  volatile didn   t solve this issue

User · Answer

It s important to understand that there are two aspects to thread safety    execution control  and memory visibility     The first has to do with controlling when code executes  including the order in which instructions are executed  and whether it can execute concurrently  and the second to do with when the effects in memory of what has been done are visible to other threads   Because each CPU has several levels of cache between it and main memory  threads running on different CPUs or cores can see  memory  differently at any given moment in time because threads are permitted to obtain and work on private copies of main memory   Using synchronized prevents any other thread from obtaining the monitor  or lock  for the same object  thereby preventing all code blocks protected by synchronization on the same object from executing concurrently   Synchronization also creates a  happens-before  memory barrier  causing a memory visibility constraint such that anything done up to the point some thread releases a lock appears to another thread subsequently acquiring the same lock to have happened before it acquired the lock  In practical terms  on current hardware  this typically causes flushing of the CPU caches when a monitor is acquired and writes to main memory when it is released  both of which are  relatively  expensive   Using volatile  on the other hand  forces all accesses  read or write  to the volatile variable to occur to main memory  effectively keeping the volatile variable out of CPU caches  This can be useful for some actions where it is simply required that visibility of the variable be correct and order of accesses is not important  Using volatile also changes treatment of long and double to require accesses to them to be atomic  on some  older  hardware this might require locks  though not on modern 64 bit hardware  Under the new  JSR-133  memory model for Java 5   the semantics of volatile have been strengthened to be almost as strong as synchronized with respect to memory visibility and instruction ordering  see http   www cs umd edu users pugh java memoryModel jsr-133-faq html volatile    For the purposes of visibility  each access to a volatile field acts like half a synchronization      Under the new memory model  it is still true that volatile variables cannot be reordered with each other  The difference is that it is now no longer so easy to reorder normal field accesses around them  Writing to a volatile field has the same memory effect as a monitor release  and reading from a volatile field has the same memory effect as a monitor acquire  In effect  because the new memory model places stricter constraints on reordering of volatile field accesses with other field accesses  volatile or not  anything that was visible to thread A when it writes to volatile field f becomes visible to thread B when it reads f       -- JSR 133  Java Memory Model  FAQ   So  now both forms of memory barrier  under the current JMM  cause an instruction re-ordering barrier which prevents the compiler or run-time from re-ordering instructions across the barrier  In the old JMM  volatile did not prevent re-ordering  This can be important  because apart from memory barriers the only limitation imposed is that   for any particular thread  the net effect of the code is the same as it would be if the instructions were executed in precisely the order in which they appear in the source   One use of volatile is for a shared but immutable object is recreated on the fly  with many other threads taking a reference to the object at a particular point in their execution cycle   One needs the other threads to begin using the recreated object once it is published  but does not need the additional overhead of full synchronization and it s attendant contention and cache flushing      Declaration public class SharedLocation       static public SomeObject someObject new SomeObject       default object           Publishing code    Note  do not simply use SharedLocation someObject xxx    since although          someObject will be internally consistent for xxx    a subsequent           call to yyy   might be inconsistent with xxx   if the object was           replaced in between calls  SharedLocation someObject new SomeObject          new object is published     Using code private String getError         SomeObject myCopy SharedLocation someObject     gets current copy             int cod myCopy getErrorCode        String txt myCopy getErrorText        return  cod   -   txt            And so on  with myCopy always in a consistent state within and across calls    Eventually we will return to the code that gets the current SomeObject    Speaking to your read-update-write question  specifically   Consider the following unsafe code   public void updateCounter         if counter  1000    counter 0        else                counter              Now  with the updateCounter   method unsynchronized  two threads may enter it at the same time   Among the many permutations of what could happen  one is that thread-1 does the test for counter  1000 and finds it true and is then suspended  Then thread-2 does the same test and also sees it true and is suspended  Then thread-1 resumes and sets counter to 0  Then thread-2 resumes and again sets counter to 0 because it missed the update from thread-1   This can also happen even if thread switching does not occur as I have described  but simply because two different cached copies of counter were present in two different CPU cores and the threads each ran on a separate core  For that matter  one thread could have counter at one value and the other could have counter at some entirely different value just because of caching   What s important in this example is that the variable counter was read from main memory into cache  updated in cache and only written back to main memory at some indeterminate point later when a memory barrier occurred or when the cache memory was needed for something else  Making the counter volatile is insufficient for thread-safety of this code  because the test for the maximum and the assignments are discrete operations  including the increment which is a set of non-atomic read increment write machine instructions  something like    MOV EAX counter INC EAX MOV counter EAX   Volatile variables are useful only when all operations performed on them are  atomic   such as my example where a reference to a fully formed object is only read or written  and  indeed  typically it s only written from a single point   Another example would be a volatile array reference backing a copy-on-write list  provided the array was only read by first taking a local copy of the reference to it

[java] Difference between volatile and synchronized in Java

Examples related to java

Examples related to multithreading

Examples related to java-me

Examples related to synchronized

Examples related to volatile