Concurrency model-Shared memory model (threads and locks) sample Chapter

The shared memory model, as its name implies, is the implementation of concurrent models through shared memory, and when multiple threads use shared resources in concurrent execution, such as reading dirty data, invalid data, and so on, if they are not contracted or specially handled by shared resources, in order to solve these problems caused by shared resources, Java introduces synchronization, locks, atomic types and other operations to handle shared resources;
In this article, we will introduce several demos of Java synchronized, lock, atomic related classes, Java Shared memory concurrency model is also embodied in synchronization (synchronized), lock, and other such implementations;

Synchronous:
The demo opens two threads to call a counter, when the counter is two threads of shared resources, two threads in the competition shared resources have occurred in the condition of the conditions, when the condition is not processed when the data obtained may be abnormal incorrect;

1 /**2 * Created by Linx on 2015-05-12.3  */4  Public classCounter {6     Private intCount = 0; 8      Public  voidincrement () {9++count;Ten     } A      Public intGetCount () { -         returncount; -     } the } - /** - * Created by Linx on 2015-05-12. -  */ +  Public classCountthreadextendsThread { -  +     PrivateCounter Counter; A      PublicCountthread (Counter Counter) { at          This. Counter =counter; -     } - @Override -      Public voidrun () { -          for(inti = 0; I < 5000; i++) { - counter.increment (); in         } -     } to } + /** - * Created by Linx on 2015-05-12. the  */ *  Public classCountmain { $ Panax Notoginseng      Public Static voidMain (string[] args)throwsinterruptedexception { -  theCounter Counter =NewCounter (); +Atomiccounter atomiccounter=NewAtomiccounter (); ACountthread T1 =Newcountthread (counter); theCountthread t2 =Newcountthread (counter); + T1.start (); - T2.start (); $ T1.join (); $ T2.join (); - System.out.println (Counter.getcount ()); -     }  the}

When I execute this code, almost every time I get the result is different, the result is as follows:

The result is unpredictable because there are conditions in the State;
The method to solve the conditions of the condition is to lock the competition resources to lock and synchronize, in Java can use synchronized or lock lock;
Now let's modify the code for the counter:

 Public synchronized void increment () {  + +count;}

Here we just add the Synchronized keyword to the increment method declaration, when we are executing the program, and now every time we get the result will be 10000,
Because we have solved the condition of the state, one thread will go into the increment method at the same time, so the right result is obtained.

Lock
Here we just replace the synchronized in the above demo with the lock object, the result is the same;

/*** Created by Linx on 2015-05-12.*/ Public classCounter {Private intCount = 0; Lock Lock=NewReentrantlock ();  Public  voidincrement () {lock.lock (); Try {            ++count; }finally{lock.unlock (); }    }     Public intGetCount () {returncount; }}  

Here we show the use of the Reentrantlock lock object to the increment method to lock the code block, the other synchronized is also to lock the method, but it uses the object's built-in lock;
Atomic type
We above the demo only so there is no synchronization or lock when the problem occurs because ++count is not atomic, it is actually read-modify-write three operations, as long as the increment can be guaranteed as an atomic method then there is no problem here, Now let's do it. Count is changed to atomic type;

/***/Publicclass  atomiccounter    {private Atomicinteger count=New  Atomicinteger ();      Public  void increment () {        count.incrementandget ();    }       Public Atomicinteger GetCount () {        return  count;    }}

This counter class does not make any synchronization or lock-up without any problems, because the increment method is atomic.

Model Pros and cons
Advantage: the memory-sharing model or thread-to-lock model is widely used, and it is now available in almost every operating system, so it is also a non-common model.

Disadvantage: There are some problems with the thread and lock model, there is no direct support for concurrent, unable or difficult to implement distributed shared memory system, threading and locking model has a very bad place is difficult to test, in multithreaded programming many times inadvertently there is a problem at this time do not know, And when suddenly the bug is often we also difficult to reproduce the bug, shared memory model is not a mathematical model, there is a great uncertainty, and uncertainty indicates that may hide the problem, people's thinking is only single-threaded;

Also because the creation of the thread is also very resource-intensive, and multi-threaded conditions, locks and other competition if the processing is not good also will affect the performance;

Article starting address: Solinx
http://www.solinx.co/archives/190

Concurrency model-Shared memory model (threads and locks) sample Chapter