方法上加上 synchronized 就可以了么

我们先来看一段代码

public static void main(String[] args) {
    
    
       DemoController demoController = new DemoController();
       new Thread(() -> demoController.sum()).start();
       new Thread(() -> demoController.isEqual()).start();
   }

   private volatile int counter1 = 0;
   private volatile int counter2 = 0;


   public void sum () {
    
    
       IntStream.rangeClosed(0, 1000).boxed().forEach(i -> {
    
    
           counter1 += i;
           counter2 += i;
       });
   }

   public void isEqual () {
    
    
       IntStream.rangeClosed(0, 1000).boxed().forEach(i -> {
    
    
           if (counter1 != counter2) {
    
    
               System.out.println("counter1 != counter2 counter1 = " + counter1 + " counter2 = " + counter2);
           }
       });
   }

代码中定义两个变量 counter1 和 counter2 ， 方法 sum 对两个变量循环 1000 次进行求和；

方法 isEqual 对这两个变量进行测试看是否一直相等。如果一直相等，程序结束后是不会有输出的。从代码上来看， 我们在 sum 方法中同时对 counter1 和 counter2 进行加和， 它们应该说是一直相等的。 但是运行之后，我们会发现程序结束后有很多次都出现了 counter1 和 counter2 不相等的情况。

对多线程敏感的朋友其实一眼就看到了，说，你这是多线程操作，需要保证多个操作换原子性，这样才能保证 counter1 和 counter2 时刻相等。

那这个代码要怎么改造呢？

既然 sum 方法不是原子性操作，那我们给 sum 方法无脑加上 synchronized 不就好了么？

public synchronized void sum () {
    
    
       IntStream.rangeClosed(0, 1000).boxed().forEach(i -> {
    
    
           counter1 += i;
           counter2 += i;
       });
   }

这样可以解决问题么？ 我们运行看一下：

没有内容输出，好像真的可以！别急，我们多运行几次程序

是的，高兴早了，并没有解决问题。

那为什么呢，我们在 sum 方法前面加上了 synchronized 关键字，保证了 sum 方法的操作原子性， 为啥不能解决这个问题呢？回过头来，我们再看看代码，会发现 sum 和 isEqual 方法运行在两个不同的线程中，thread1 运行的 sum 方法， thread2 运行的 isEqual 方法， 我们只保证 sum 方法的原子性是行的，因为 sum 方法至始至终都只运行在 thread1 中，并没有产生多线程的并发问题。产生并发问题的是 sum 方法和 isEqual 方法之间。所以要想解决这个问题应该是在 sum 和 isEqual 方法都加上 synchronized 关键字

public synchronized void sum () {
    
    
       IntStream.rangeClosed(0, 1000).boxed().forEach(i -> {
    
    
           counter1 += i;
           counter2 += i;
       });
   }

   public synchronized void isEqual () {
    
    
       IntStream.rangeClosed(0, 1000).boxed().forEach(i -> {
    
    
           if (counter1 != counter2) {
    
    
               System.out.println("counter1 != counter2 counter1 = " + counter1 + " counter2 = " + counter2);
           }
       });
   }

运行一下看看结果

这样看起来才是真正把这个问题给解决了。

---

我们回过头来看看为什么会出现这种误区：在没有保证原子性的地方加上 synchronized 关键字保证原子性即可。

1. 需要明确谁是共享变量
2. 共享变量在哪里出现了资源的竞争
3. 在哪里出现资源的竞争才需要在哪里加锁

上面的例子中， 共享变量就是 counter1 和 counter2 ；counter1 和 counter2 在 执行 sum 和 isEqual 时才出现了资源的竞争；所以我们要在 sum 和 isEqual 中加上 synchronized

为什么锁不住

再来看一个例子

public static void main(String[] args) {
    
    
       IntStream.rangeClosed(1, 10000).boxed().parallel().forEach(i -> new DemoController().add());
       System.out.println(DemoController.getA());
   }

   private static int a;

   public synchronized void add() {
    
    
       a++;
   }

   public static int getA() {
    
    
       return a;
   }

这个例子中， 一个共享变量 a, 一个方法 add 每次 +1 ，现在10000个并发对 a 变量进行加1 操作，最后输出 a 的值。add 方法前我们加了 synchronized ，按照预期来讲，我们 getA() 的时候应该得到的是 10000， 但真的是这样么？我们运行一下：

很遗憾，结果并不是我们想要的。为什么会这样呢？

我们也严格按照前面讲的来做了呀：明确了 a 是共享变量；资源在 add 方法中出现了竞争；在 add 方法上加了 synchronized。

这是因为我们还要搞清楚一件事：我们加锁，锁的是谁

在这个例子中，变量 a 是静态的，它的锁级别应该是类级别的， 而 add 方法不静态方法， 在前面加上 synchronized ，锁的只是DemoController 类的某个实例，所以会出现明明加了 synchronized 还是出现并发问题。

既然知道了问题的所在，那就很好解决了。我们只需要把锁加在类级别上就可以了。

private static int a;

   private static Object locker = new Object();

   public void add() {
    
    
       synchronized (locker) {
    
    
           a++;
       }
   }

定义一个静态的 Object 对象用来当作锁的标志量，synchronized 锁的是 locker 这个标志量，那么这样这个锁就是在类级别了。我们再来验证一下

哪哪都是 synchronized

方法上加 synchronized 关键字实现加锁确实很爽，那假如涉及到共享变量的方法都加了 synchronized，这个系统会变成什么样呢？想想都可怕。 这种不管三七二十一的 加上 synchronized 的做法有以下几个坏处：

1. 真的没必要！通常情况我们的系统都是MVC三层架构，数据经过无状态的 Controller、Service、DAO 流转到DB，没必要使用 synchronized 来保护什么共享资源数据。
2. 极大地降低性能！使用 Spring 框架时，默认情况下 Controller、Service、Repository 是单例的，加上 synchronized 会导致整个程序几乎就只能支持单线程，造成极大的性能问题，并发量大大降低。

那如果我们确实有一些共享数据需要保护，怎么办呢？

那我们需要要尽可能降低锁的粒度，仅对必要的代码块甚至是需要保护的资源本身加锁。

比如前段时间，有一个业务场景：有一个线程共享的 List， 里面存的是当前活跃的连接信息。

List 又有一段比较耗时的操作，但是不涉及到线程安全问题，那么我们应该如何加锁呢？

private List<Integer> list = new ArrayList<>();

   //不涉及共享资源的慢方法
   private void compute() {
    
    
       try {
    
     TimeUnit.MILLISECONDS.sleep(10); } catch (InterruptedException e) {
    
     }
   }

   @GetMapping("long")
   public void lon9() {
    
    
       long start = System.currentTimeMillis();
       IntStream.rangeClosed(0, 1000).boxed().parallel().forEach(i -> {
    
    
           synchronized (this) {
    
    
               compute();
               list.add(i);
           }
       });
       log.info("花费时间为: {}", (System.currentTimeMillis() - start) / 1000.0);
   }

   @GetMapping("short")
   public void sh0rt() {
    
    
       long start = System.currentTimeMillis();
       IntStream.rangeClosed(0, 1000).boxed().parallel().forEach(i -> {
    
    
           compute();
           synchronized (this) {
    
    
               list.add(i);
           }
       });
       log.info("花费时间为: {}", (System.currentTimeMillis() - start) / 1000.0);
   }

上面代码中，有一个共享资源 list， 对 list 会进行比较耗时的计算操作，另一个是模拟多个请求，long 接口 synchronized 的范围比较大， 运行结果可以看到， 耗时有 11s+ , short 接口synchronized 只进行了必要地方的进行括起来，耗时只有 1s+ 。

从这个例子中我们可以看到，使用 synchronized 对系统的性能影响是很大的。业务中真的要用到的地方一定要减小粒度。

那么问题来了，锁范围已经不能再缩小了，性能还无法满足需求的话，我们就要考虑另一个的粒度问题了。

即：区分读写场景以及资源的访问冲突，考虑使用悲观方式的锁还是乐观方式的锁。

常见的业务代码中，很少需要进一步考虑这两种更细粒度的锁，所以我就只说几个大概的结论。然后根据自己的需求来考虑是否有必要进一步优化：

1. 对于读写比例差异明显的场景，考虑使用 ReentrantReadWriteLock 细化区分读写锁，来提高性能。
2. JDK 里 ReentrantLock 和 ReentrantReadWriteLock 都提供了公平锁的版本，在没有特殊的情况下不要轻易开启公平锁特性，在任务不重的情况下开启公平锁可能会让性能指数级下降