Mention lock , You must be thinking sychronized keyword . It can solve all concurrent problems , however , For higher system throughput requirements , Here are some tips . Help you reduce lock granularity , Improve concurrency .
Basic skills - Optimistic lock
The scenario of optimistic lock is , No conflict in reading , Write meeting conflict . Simultaneous reading is much more frequent than writing .
The realization of pessimistic lock ：
Pessimistic that all code execution will have concurrent problems , So use all code blocks sychronized lock up
The realization of optimistic lock ：
Optimistic that there will be no conflict in reading , Add lock on write . So the application scenario to be solved is the scenario when reading is far greater than writing .
Intermediate skills -String.intern()
Optimistic lock can't solve a lot of write conflicts , But in many scenarios , Lock is only for a user or an order .
For example, a user creates session, Then we can carry out the following operations , But because of the network problems , establish session Of requests and subsequent requests arrive almost at the same time , Parallel threads may process subsequent requests first . Generally speaking, it is necessary to sessionMap Lock up , Like the optimistic lock on it . In such a scenario , Locks can be limited to the user , That is, the original
This is similar to the concept of row lock and database table lock . Obviously, the concurrency of row locks is much higher than that of table locks .
practical String.intern(); Is the concrete realization of this way . class String A string pool is maintained . When called intern Method time , If the pool already contains a String Object's string （ The object is created by equals(Object) Method determination ）, Returns the string in the pool . so , When String
When the same , Always return the same object , Therefore, the same user is locked . Because the particle size is limited to specific users , Maximize the concurrency of the system .
Now that it's said “ Similar to the concept of row lock in database ”, I have to mention it MVCC,Java in CopyOnWrite Class implements MVCC.Copy On
Write It's a mechanism . When we read shared data , Direct read , No synchronization required . When we modify the data , Let's put the current data Copy One copy , And then in this copy
Modified on , After completion , Use the modified copy again , Replace the original data . This method is called Copy On Write.
however ,,,JDK Not provided CopyOnWriteMap, Why? ? Here's a good answer , That's already there ConcurrentHashMap, Why is it necessary CopyOnWriteMap?
Advanced skills - class ConcurrentHashMap
String.inter() The defect of is class String To maintain a string pool is to place JVM
perm Regional , If there are too many users , Causes the String Uncontrollable , May cause OOM Wrong or too many Full
GC. How to control the number of locks , At the same time, reduce the particle size ? Direct use Java
ConcurrentHashMap? Or you want to add your own finer control ? So we can learn from it ConcurrentHashMap How , Divide the objects to be locked into several bucket, each bucket Add a lock , The pseudo code is as follows ：