对包装类型变量使用synchronized不当造成的同步不正确
关于关键字synchronized使用不当，造成未同步或者同步不正确，是开发过程中常见的问题。先引出3个问题：
- 同步synchronized的底层实现原理是什么？
- 对非常量或者非单例对象上使用synchronized，会有什么效果？
- 对包装类型使用synchronized，会有什么效果？
同步synchronized的底层实现原理是什么？
在对象上使用synchronized，会尝试获取对象的锁。获取成功之后，程序可以进入到同步代码块中执行逻辑。如果获取失败，则会进入到等待该对象锁的等待队列中。
对象锁是非公平的（可以使用java.util.concurrent.locks.Lock的实现类实现公平锁，当然会有额外的性能消耗），也就是说，唤醒线程时，并不参考其等待时间，在极端情况下，线程会出现饿死的情况。
通过synchronized使用对象锁，不需要显示地获取或者释放锁。在编译（前端编译，即javac或者类似编译器，不是JIT编译）过后，如果synchronized同步的是代码块，字节码文件中会存在monitorenter与monitorexit，2个虚拟机指令实现代码块的进入与退出，这也是虚拟机规范之一。而同步方法则不会显示这两个指令，因为同步方法的实现细节不属于虚拟机规范，各个商用虚拟机会有不同的细节，当然，也可以通过monitorenter和monitorexit来实现。感兴趣的读者可以动手写个简单的类，通过命令查看反编译后的执行指令。
javap -c -p yourPath/TestClass 注：TestClass是类名，不是TestClass.class或者TestClass.java等文件名。
对非常量或者非单例对象上使用synchronized，会有什么效果？
理解了synchronized的实现原理，就来看看对非常量或者非单例对象上使用synchronized，会有什么效果。
显而易见，当不是常量或者非单例，不同的执行线程有可能会在不同的对象上获取、释放锁，这些不同的对象是不会互相影响的，所以有可能会出现没有同步的情况。
所以，当我们使用一个内部私有对象实现同步的时候，需要将该变量定义成常量，如：
private static final Object monitor = new Object();对于Spring等对象容器来说，你需要关注通过配置文件往容器加入的对象，是否是单例（Spring默认是单例，既scope = singleton）。非单例的对象，当应用程序向容器索取对象时，容器可能会返回一个新建的对象。
对包装类型使用synchronized，会有什么效果？
首先，因为包装类型是对象，所以对包装类型使用synchronized同样适用第2点，即存在非常量及非单例对同步逻辑的影响。
其次，包装类型有特殊的逻辑。当把基本变量赋值给包装类型的变量（其实编译过后的操作就是调用包装类型的静态方法valueOf）或者调用静态valueOf方法时：
- Boolean返回的是缓存的对象。
- 整型（Byte,Short,Integer,Long）会检查该数字是否在1个字节可表示的有符号整数范围内（-128~127），是则返回缓存对象，否则返回新对象。
- Character会缓存整型值为0~127的字符，同样会检查字符是否落在缓存范围中，是则返回，否则返回新对象。
- Double和Float的valueOf方法始终返回新对象。
所以，当我们对非常量的包装类型，如Boolean类型的变量上使用同步时，比如：
public Boolean flag = false; ... //thread1 synchronized (flag) { ... }如果另外的线程thread2执行了flag = true，即flag = Boolean.valueOf(true)，之后又马上获取flag的对象锁，假设Boolean缓存的TRUE的对象锁可用的情况下，线程会立即执行同步代码，此时程序的行为看上去像是同步失效了。
不过运气好的话，执行flag = false后立即获取对象锁，则thread2会等到thread1执行完毕后才进入同步代码块，同步会生效，因为获取的是同一个对象锁。
因此，这种程序不仅是面向对象的程序，还是面向对象的运气程序。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
