锁的消除

末蓝、 2022-10-23 00:47 174阅读 0赞

总括：

1，jvm安装的是server模式

2，配置jvm锁消除

3，枷锁的变量是方法内的局部变量，此时jvm在运行时会检测同步块的是否是局部变量，是的话就消除锁，提高效率

锁粗化

通常情况下，为了保证多线程间的有效并发，会要求每个线程持有锁的时间尽可能短，但是大某些情况下，一个程序对同一个锁不间断、高频地请求、同步与释放，会消耗掉一定的系统资源，因为锁的讲求、同步与释放本身会带来性能损耗，这样高频的锁请求就反而不利于系统性能的优化了，虽然单次同步操作的时间可能很短。**锁粗化就是告诉我们任何事情都有个度，有些情况下我们反而希望把很多次锁的请求合并成一个请求，以降低短时间内大量锁请求、同步、释放带来的性能损耗。**

一种极端的情况如下：

1.  `public void doSomethingMethod(){`
2.  `synchronized(lock){`
3.  `//do some thing`
4.  `}`
5.  `//这是还有一些代码，做其它不需要同步的工作，但能很快执行完毕`
6.  `synchronized(lock){`
7.  `//do other thing`
8.  `}`
9.  `}`

上面的代码是有两块需要同步操作的，但在这两块需要同步操作的代码之间，需要做一些其它的工作，而这些工作只会花费很少的时间，那么我们就可以把这些工作代码放入锁内，将两个同步代码块合并成一个，以降低多次锁请求、同步、释放带来的系统性能消耗，合并后的代码如下:

1.  `public void doSomethingMethod(){`
2.  `//进行锁粗化：整合成一次锁请求、同步、释放`
3.  `synchronized(lock){`
4.  `//do some thing`
5.  `//做其它不需要同步但能很快执行完的工作`
6.  `//do other thing`
7.  `}`
8.  `}`

> 注意：这样做是有前提的，就是中间不需要同步的代码能够很快速地完成，如果不需要同步的代码需要花很长时间，就会导致同步块的执行需要花费很长的时间，这样做也就不合理了。

另一种需要锁粗化的极端的情况是：

1.  `for(int i=0;i<size;i++){`
2.  `synchronized(lock){`
3.  `}`
4.  `}`

上面代码每次循环都会进行锁的请求、同步与释放，看起来貌似没什么问题，且在jdk内部会对这类代码锁的请求做一些优化，但是还不如把加锁代码写在循环体的外面，这样一次锁的请求就可以达到我们的要求，除非有特殊的需要：循环需要花很长时间，但其它线程等不起，要给它们执行的机会。

锁粗化后的代码如下：

1.  `synchronized(lock){`
2.  `for(int i=0;i<size;i++){`
3.  `}`
4.  `}`

锁消除

锁消除是发生在编译器级别的一种锁优化方式。  
有时候我们写的代码完全不需要加锁，却执行了加锁操作。

比如，StringBuffer类的append操作：

1.  `@Override`
2.  `public synchronized StringBuffer append(String str) {`
3.  `toStringCache = null;`
4.  `super.append(str);`
5.  `return this;`
6.  `}`

从源码中可以看出，append方法用了synchronized关键词，它是线程安全的。但我们可能仅在线程内部把StringBuffer当作局部变量使用：

1.  `package com.leeib.thread;`
2.  `public class Demo {`
3.  `public static void main(String[] args) {`
4.  `long start = System.currentTimeMillis();`
5.  `int size = 10000;`
6.  `for (int i = 0; i < size; i++) {`
7.  `createStringBuffer("Hyes", "为分享技术而生");`
8.  `}`
9.  `long timeCost = System.currentTimeMillis() - start;`
10. `System.out.println("createStringBuffer:" + timeCost + " ms");`
11. `}`
12. `public static String createStringBuffer(String str1, String str2) {`
13. `StringBuffer sBuf = new StringBuffer();`
14. `sBuf.append(str1);// append方法是同步操作`
15. `sBuf.append(str2);`
16. `return sBuf.toString();`
17. `}`
18. `}`

代码中createStringBuffer方法中的局部对象sBuf，就只在该方法内的作用域有效，不同线程同时调用createStringBuffer()方法时，都会创建不同的sBuf对象，因此此时的append操作若是使用同步操作，就是白白浪费的系统资源。

这时我们可以通过编译器将其优化，将锁消除，前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸分析:

\-server -XX:+DoEscapeAnalysis -XX:+EliminateLocks

其中+DoEscapeAnalysis表示开启逃逸分析，+EliminateLocks表示锁消除。

> 逃逸分析：比如上面的代码，它要看sBuf是否可能逃出它的作用域？如果将sBuf作为方法的返回值进行返回，那么它在方法外部可能被当作一个全局对象使用，就有可能发生线程安全问题，这时就可以说sBuf这个对象发生逃逸了，因而不应将append操作的锁消除，但我们上面的代码没有发生锁逃逸，锁消除就可以带来一定的性能提升。

转载自： [java锁优化的5个方法][java_5]

====================================================

锁削除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行削除。锁削除的主要判定依据来源于逃逸分析的数据支持，如果判断到一段代码中，在堆上的所有数据都不会逃逸出去被其他线程访问到，那就可以把它们当作栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。   
　　也许读者会有疑问，变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是程序员自己应该是很清楚的，怎么会在明知道不存在数据争用的情况下要求同步呢？答案是有许多同步措施并不是程序员自己加入的，同步的代码在Java程序中的普遍程度也许超过了大部分读者的想象。我们来看看下面代码清单13-6中的例子，这段非常简单的代码仅仅是输出三个字符串相加的结果，无论是源码字面上还是程序语义上都没有同步。   
  
　　代码清单 13-6 一段看起来没有同步的代码

Java代码   [![收藏代码][0acc010f4156c3bef8ac764059e910f5.png]][0acc010f4156c3bef8ac764059e910f5.png 1]

1.  public String concatString(String s1, String s2, String s3) \{  
2.      return s1 + s2 + s3;  
3.  \}

我们也知道，由于String是一个不可变的类，对字符串的连接操作总是通过生成新的String对象来进行的，因此Javac编译器会对String连接做自动优化。在JDK 1.5之前，会转化为StringBuffer对象的连续append()操作， 在JDK 1.5及以后的版本中，会转化为StringBuilder对象的连续append()操作。 即代码清单13-6中的代码可能会变成代码清单13-7的样子 。   
  
　　代码清单 13-7 Javac转化后的字符串连接操作

Java代码   [![收藏代码][0acc010f4156c3bef8ac764059e910f5.png]][0acc010f4156c3bef8ac764059e910f5.png 1]

1.  public String concatString(String s1, String s2, String s3) \{  
2.      StringBuffer sb = new StringBuffer();  
3.      sb.append(s1);  
4.      sb.append(s2);  
5.      sb.append(s3);  
6.      return sb.toString();  
7.  \}

（注1：实事求是地说，既然谈到锁削除与逃逸分析，那虚拟机就不可能是JDK 1.5之前的版本，所以实际上会转化为非线程安全的StringBuilder来完成字符串拼接，并不会加锁。但是这也不影响笔者用这个例子证明Java对象中同步的普遍性。）    
  
　　现在大家还认为这段代码没有涉及同步吗？每个StringBuffer.append()方法中都有一个同步块，锁就是sb对象。虚拟机观察变量sb，很快就会发现它的动态作用域被限制在concatString()方法内部。也就是sb的所有引用永远不会“逃逸”到concatString()方法之外，其他线程无法访问到它，所以这里虽然有锁，但是可以被安全地削除掉，在即时编译之后，这段代码就会忽略掉所有的同步而直接执行了。

=====================================

This is an example of manual "[lock coarsening][]" and may have been done to get a performance boost.

Consider these two snippets:

1.  `StringBuffer b = new StringBuffer();`
2.  `for(int i = 0 ; i < 100; i++){`
3.  `b.append(i);`
4.  `}`

versus:

1.  `StringBuffer b = new StringBuffer();`
2.  `synchronized(b){`
3.  `for(int i = 0 ; i < 100; i++){`
4.  `b.append(i);`
5.  `}`
6.  `}`

In the first case, the StringBuffer must acquire and release a lock 100 times (because `append` is a synchronized method), whereas in the second case, the lock is acquired and released only once. This can give you a performance boost and is probably why the author did it. In some cases, the compiler can perform this [lock coarsening][] for you (but not around looping constructs because you could end up holding a lock for long periods of time).

By the way, the compiler can detect that an object is not "escaping" from a method and so remove acquiring and releasing locks on the object altogether (lock elision) since no other thread can access the object anyway. A lot of work has been done on this in [JDK7][].

转载自： [Synchronization on the local variables][]

===================================

转载自：[Java锁消除][Java]

非商业转载，可联系本人删除

## 概述 ##

锁消除是Java虚拟机在JIT编译是，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过锁消除，可以节省毫无意义的请求锁时间。

## 实验 ##

看如下代码：

1.  `package com.winwill.lock;`
2.   
3.  `/**`
4.  `* @author qifuguang`
5.  `* @date 15/6/5 14:11`
6.  `*/`
7.  `public class TestLockEliminate {`
8.  `public static String getString(String s1, String s2) {`
9.  `StringBuffer sb = new StringBuffer();`
10. `sb.append(s1);`
11. `sb.append(s2);`
12. `return sb.toString();`
13. `}`
14.  
15. `public static void main(String[] args) {`
16. `long tsStart = System.currentTimeMillis();`
17. `for (int i = 0; i < 1000000; i++) {`
18. `getString("TestLockEliminate ", "Suffix");`
19. `}`
20. `System.out.println("一共耗费：" + (System.currentTimeMillis() - tsStart) + " ms");`
21. `}`
22. `}`

getString()方法中的StringBuffer数以函数内部的局部变量，进作用于方法内部，不可能逃逸出该方法，因此他就不可能被多个线程同时访问，也就没有资源的竞争，但是StringBuffer的append操作却需要执行同步操作:

1.  `@Override`
2.  `public synchronized StringBuffer append(String str) {`
3.  `toStringCache = null;`
4.  `super.append(str);`
5.  `return this;`
6.  `}`

逃逸分析和锁消除分别可以使用参数-XX:+DoEscapeAnalysis和-XX:+EliminateLocks(锁消除必须在-server模式下)开启。使用如下参数运行上面的程序：

> \-XX:+DoEscapeAnalysis -XX:-EliminateLocks

得到如下结果：   
![这里写图片描述][20150605143406270]

使用如下命令运行程序：

> \-XX:+DoEscapeAnalysis -XX:+EliminateLocks

得到如下结果：   
![这里写图片描述][20150605143628409]

## 结论 ##

由上面的例子可以看出，关闭了锁消除之后，StringBuffer每次append都会进行锁的申请，浪费了不必要的时间，开启锁消除之后性能得到了提高。

[java_5]: http://www.hao124.net/article/70
[0acc010f4156c3bef8ac764059e910f5.png]: https://img-blog.csdnimg.cn/img_convert/0acc010f4156c3bef8ac764059e910f5.png
[0acc010f4156c3bef8ac764059e910f5.png 1]: /images/20221022/8deb2dd062d54eba87b5346b1deda756.png
[lock coarsening]: http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.2
[JDK7]: http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html
[Synchronization on the local variables]: https://stackoverflow.com/questions/6123024/synchronization-on-the-local-variables
[Java]: https://blog.csdn.net/winwill2012/article/details/46376679
[20150605143406270]: /images/20221022/1c0a349fae2e4423982ffd419d2eab9e.png
[20150605143628409]: /images/20221022/92681f5b61ce4c20ac46c5261085bb7a.png