并发容器ConcurrentHashMap与synchronized联合使用达到线程安全

最近做的项目中遇到一个问题：明明用了ConcurrentHashMap，可是始终线程不安全除去项目中的业务逻辑，简化后的代码如下：[java] viewplain copypublic class Test40 { public static void main(String[] args) throws In

追赶的蜗牛

6615人浏览 · 2016-02-14 22:54:43

追赶的蜗牛 · 2016-02-14 22:54:43 发布

最近做的项目中遇到一个问题：明明用了ConcurrentHashMap，可是始终线程不安全

除去项目中的业务逻辑，简化后的代码如下：

[java]view plain copy 
   
 public class Test40 {  
   
     public static void main(String[] args) throws InterruptedException {  
         for (int i = 0; i < 10; i++) {  
             System.out.println(test());  
         }  
     }  
       
     private static int test() throws InterruptedException {  
         ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<String, Integer>();  
         ExecutorService pool = Executors.newCachedThreadPool();  
         for (int i = 0; i < 8; i++) {  
             pool.execute(new MyTask(map));  
         }  
         pool.shutdown();  
         pool.awaitTermination(1, TimeUnit.DAYS);  
           
         return map.get(MyTask.KEY);  
     }  
 }  
   
 class MyTask implements Runnable {  
       
     public static final String KEY = "key";  
       
     private ConcurrentHashMap<String, Integer> map;  
       
     public MyTask(ConcurrentHashMap<String, Integer> map) {  
         this.map = map;  
     }  
   
     @Override  
     public void run() {  
         for (int i = 0; i < 100; i++) {  
             this.addup();  
         }  
     }  
       
     private void addup() {  
         if (!map.containsKey(KEY)) {  
             map.put(KEY, 1);  
         } else {  
             map.put(KEY, map.get(KEY) + 1);  
         }      
     }  
 }  

测试代码跑了10次，每次都不是800。这就很让人疑惑了，难道ConcurrentHashMap的线程安全性失效了？

查了一些资料后发现，原来ConcurrentHashMap的线程安全指的是，它的每个方法单独调用（即原子操作）都是线程安全的，但是代码总体的互斥性并不受控制。以上面的代码为例，最后一行中的：

[java]view plain copy 
   
 map.put(KEY, map.get(KEY) + 1);  

实际上并不是原子操作，它包含了三步：

map.get
加1
map.put

其中第1和第3步，单独来说都是线程安全的，由ConcurrentHashMap保证。但是由于在上面的代码中，map本身是一个共享变量。当线程A执行map.get的时候，其它线程可能正在执行map.put，这样一来当线程A执行到map.put的时候，线程A的值就已经是脏数据了，然后脏数据覆盖了真值，导致线程不安全

简单地说，ConcurrentHashMap的get方法获取到的是此时的真值，但它并不保证当你调用put方法的时候，当时获取到的值仍然是真值

为了使上面的代码变得线程安全，我引入了synchronized关键字来修饰目标方法，如下：

[java]view plain copy 
   
 public class Test40 {  
   
     public static void main(String[] args) throws InterruptedException {  
         for (int i = 0; i < 10; i++) {  
             System.out.println(test());  
         }  
     }  
       
     private static int test() throws InterruptedException {  
         ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<String, Integer>();  
         ExecutorService pool = Executors.newCachedThreadPool();  
         for (int i = 0; i < 8; i++) {  
             pool.execute(new MyTask(map));  
         }  
         pool.shutdown();  
         pool.awaitTermination(1, TimeUnit.DAYS);  
           
         return map.get(MyTask.KEY);  
     }  
 }  
   
 class MyTask implements Runnable {  
       
     public static final String KEY = "key";  
       
     private ConcurrentHashMap<String, Integer> map;  
       
     public MyTask(ConcurrentHashMap<String, Integer> map) {  
         this.map = map;  
     }  
   
     @Override  
     public void run() {  
         for (int i = 0; i < 100; i++) {  
             this.addup();  
         }  
     }  
       
     private synchronized void addup() { // 用关键字synchronized修饰addup方法  
         if (!map.containsKey(KEY)) {  
             map.put(KEY, 1);  
         } else {  
             map.put(KEY, map.get(KEY) + 1);  
         }  
     }  
       
 }  

运行之后仍然是线程不安全的，难道synchronized也失效了？

查阅了synchronized的资料后，原来，不管synchronized是用来修饰方法，还是修饰代码块，其本质都是锁定某一个对象。修饰方法时，锁上的是调用这个方法的对象，即this；修饰代码块时，锁上的是括号里的那个对象

在上面的代码中，很明显就是锁定的MyTask对象本身。但是由于在每一个线程中，MyTask对象都是独立的，这就导致实际上每个线程都对自己的MyTask进行锁定，而并不会干涉其它线程的MyTask对象。换言之，上锁压根没有意义

理解到这点之后，对上面的代码又做了一次修改：

[java]view plain copy 
   
 public class Test40 {  
   
     public static void main(String[] args) throws InterruptedException {  
         for (int i = 0; i < 10; i++) {  
             System.out.println(test());  
         }  
     }  
       
     private static int test() throws InterruptedException {  
         ConcurrentHashMap<String, Integer> map = new ConcurrentHashMap<String, Integer>();  
         ExecutorService pool = Executors.newCachedThreadPool();  
         for (int i = 0; i < 8; i++) {  
             pool.execute(new MyTask(map));  
         }  
         pool.shutdown();  
         pool.awaitTermination(1, TimeUnit.DAYS);  
           
         return map.get(MyTask.KEY);  
     }  
 }  
   
 class MyTask implements Runnable {  
       
     public static final String KEY = "key";  
       
     private ConcurrentHashMap<String, Integer> map;  
       
     public MyTask(ConcurrentHashMap<String, Integer> map) {  
         this.map = map;  
     }  
   
     @Override  
     public void run() {  
         for (int i = 0; i < 100; i++) {  
             synchronized (map) { // 对共享对象map上锁  
                 this.addup();  
             }  
         }  
     }  
       
     private void addup() {  
         if (!map.containsKey(KEY)) {  
             map.put(KEY, 1);  
         } else {  
             map.put(KEY, map.get(KEY) + 1);  
         }  
     }  
       
 }  

此时在调用addup时直接锁定map，由于map是被所有线程共享的，因而达到了让所有线程互斥的目的，线程安全达成。

修改后，ConcurrentHashMap的作用就不大了，可以直接将代码中的map换成普通的HashMap，以减少由ConcurrentHashMap带来的锁开销

最后特别补充的是，synchronized关键字判断对象是否是它属于锁定的对象，本质上是通过 == 运算符来判断的。换句话说，上面的代码中，可以采用任何一个常量，或者每个线程都共享的变量，或者MyTask类的静态变量，来代替map。只要该变量与synchronized锁定的目标变量相同（==），就可以使synchronized生效

综上，代码最终可以修改为：

[java]view plain copy 
   
 public class Test40 {  
   
     public static void main(String[] args) throws InterruptedException {  
         for (int i = 0; i < 100; i++) {  
             System.out.println(test());  
         }  
     }  
       
     private static int test() throws InterruptedException {  
         Map<String, Integer> map = new HashMap<String, Integer>();  
         ExecutorService pool = Executors.newCachedThreadPool();  
         for (int i = 0; i < 8; i++) {  
             pool.execute(new MyTask(map));  
         }  
         pool.shutdown();  
         pool.awaitTermination(1, TimeUnit.DAYS);  
           
         return map.get(MyTask.KEY);  
     }  
 }  
   
 class MyTask implements Runnable {  
       
     public static Object lock = new Object();  
       
     public static final String KEY = "key";  
       
     private Map<String, Integer> map;  
       
     public MyTask(Map<String, Integer> map) {  
         this.map = map;  
     }  
   
     @Override  
     public void run() {  
         for (int i = 0; i < 100; i++) {  
             synchronized (lock) {  
                 this.addup();  
             }  
         }  
     }  
       
     private void addup() {  
         if (!map.containsKey(KEY)) {  
             map.put(KEY, 1);  
         } else {  
             map.put(KEY, map.get(KEY) + 1);  
         }  
     }  
       
 }  

向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...