java高并发锁的3种实现

怼烎@ 2022-06-14 04:28 108阅读 0赞

## 初级技巧 - 乐观锁 ##

乐观锁适合这样的场景：读不会冲突，写会冲突。同时读的频率远大于写。

以下面的代码为例，悲观锁的实现：

Java代码  ![收藏代码][icon_star.png]

1.  **public** Object get(Object key) \{  
2.     **synchronized**(map) \{  
3.        **if**(map.get(key) == **null**) \{  
4.           // set some values  
5.        \}  
6.    
7.         **return** map.get(key);  
8.     \}  
9.  \}

乐观锁的实现：

Java代码  ![收藏代码][icon_star.png]

1.  **public** Object get(Object key) \{  
2.     Object val = **null**;  
3.     **if**((val = map.get(key) == **null**) \{  
4.         // 当map取值为null时再加锁判断  
5.         **synchronized**(map) \{  
6.             **if**(val = map.get(key) == **null**) \{  
7.                 // set some value to map...  
8.             \}  
9.          \}  
10.    \}  
11.   
12.     **return** map.get(key);  
13. \}

## 中级技巧 - String.intern() ##

乐观锁不能很好解决大量写冲突问题，但是如果很多场景下，锁实际上只是针对某个用户或者某个订单。比如一个用户必须先创建session，才能进行后面的操作。但是由于网络原因，创建用户session的请求和后续请求几乎同时达到，而并行线程可能会先处理后续请求。一般情况，需要对用户sessionMap加锁，比如上面的乐观锁。在这种场景下，可以讲锁限定到用户本身上，即从原来的

lock.lock();

int num=storage.get(key);

storage.set(key,num+1);

lock.unlock();

更改为：

lock.lock(key);

int num=storage.get(key);

storage.set(key,num+1);

lock.unlock(key);

这个比较类似于数据库表锁和行锁的概念，显然行锁的并发能力比表锁高很多。

使用String.inter()是这种思路的一种具体实现。类 String 维护一个字符串池。 当调用 intern 方法时，如果池已经包含一个等于此 String 对象的字符串（该对象由 equals(Object) 方法确定），则返回池中的字符串。可见，当String相同时，String.intern()总是返回同一个对象，因此就实现了对同一用户加锁。由于锁的粒度局限于具体用户，使系统获得了最大程度的并发。

Java代码  ![收藏代码][icon_star.png]

1.  **public** **void** doSomeThing(String uid) \{  
2.     **synchronized**(uid.intern()) \{  
3.         // ...  
4.     \}  
5.  \}

CopyOnWriteMap？

既然说到了“类似于数据库中的行锁的概念”，就不得不提一下MVCC，Java中CopyOnWrite类实现了MVCC。Copy On Write是这样一种机制。当我们读取共享数据的时候，直接读取，不需要同步。当我们修改数据的时候，我们就把当前数据Copy一份副本，然后在这个副本 上进行修改，完成之后，再用修改后的副本，替换掉原来的数据。这种方法就叫做Copy On Write。

但是，，，JDK并没有提供CopyOnWriteMap，为什么？下面有个很好的回答，那就是已经有了ConcurrentHashMap，为什么还需要CopyOnWriteMap？

Fredrik Bromee 写道

I guess this depends on your use case, but why would you need a CopyOnWriteMap when you already have a ConcurrentHashMap?  
  
For a plain lookup table with many readers and only one or few updates it is a good fit.  
  
Compared to a copy on write collection:  
  
Read concurrency:  
  
Equal to a copy on write collection. Several readers can retrieve elements from the map concurrently in a lock-free fashion.  
  
Write concurrency:  
  
Better concurrency than the copy on write collections that basically serialize updates (one update at a time). Using a concurrent hash map you have a good chance of doing several updates concurrently. If your hash keys are evenly distributed.  
  
If you do want to have the effect of a copy on write map, you can always initialize a ConcurrentHashMap with a concurrency level of 1.

## 高级技巧 - 类ConcurrentHashMap ##

String.inter()的缺陷是类 String 维护一个字符串池是放在JVM perm区的，如果用户数特别多，导致放入字符串池的String不可控，有可能导致OOM错误或者过多的Full GC。怎么样能控制锁的个数，同时减小粒度锁呢？直接使用Java ConcurrentHashMap？或者你想加入自己更精细的控制？那么可以借鉴ConcurrentHashMap的方式，将需要加锁的对象分为多个bucket，每个bucket加一个锁，伪代码如下：

Java代码  ![收藏代码][icon_star.png]

1.  Map locks = **new** Map();  
2.  List lockKeys = **new** List();  
3.  **for**(**int** number : 1 - 10000) \{  
4.     Object lockKey = **new** Object();  
5.     lockKeys.add(lockKey);  
6.      locks.put(lockKey, **new** Object());  
7.  \}  
8.    
9.  **public** **void** doSomeThing(String uid) \{  
10.    Object lockKey = lockKeys.get(uid.hash() % lockKeys.size());  
11.    Object lock = locks.get(lockKey);  
12.      
13.    **synchronized**(lock) \{  
14.       // do something  
15.    \}  
16. \}  
17. ### **参考更多免费教程请加入Dubbo技术交流：[548209960][]     Java高并发高可用架构：[632103578][]** ###

[icon_star.png]: /images/20220614/412c2f9c91dc41afa854ff3cf064fec6.png
[548209960]: https://jq.qq.com/?_wv=1027&k=4A5jqU3http://
[632103578]: https://jq.qq.com/?_wv=1027&k=4A5ktbDhttp://