heat3_6的博客

举个例子吧！假设你和你的室友共用一台冰箱。你偷偷把最后一瓶可乐喝掉了，但你室友不知道，还在疯狂找可乐。这就是可见性问题——一个线程修改了数据，另一个线程却看不到最新的值。哈哈，这个例子很接地气！那volatile怎么解决这个问题呢？volatile就像是给冰箱贴了个公告：“可乐已被喝光，勿再寻找！” 每次你修改了volatile变量，都会强制把新值刷到主内存，而不是只存在线程的本地缓存里。这样，其他线程每次读取这个变量时，都会去主内存里拿最新的值，而不是用自己缓存里的旧值。volatile。

但自从Java 6之后，JVM对synchronized做了很多优化，比如引入了“偏向锁”、“轻量级锁”和“重量级锁”的机制，性能已经大幅提升。：JVM对synchronized做了很多优化，比如偏向锁、轻量级锁等，在低竞争的场景下，synchronized的性能已经足够好。而复杂场景，存在高并发和激烈的锁竞争，则需要更灵活的控制，比如超时、中断、公平锁等，我会选择ReentrantLock。阳仔：总的来说，简单场景，没有很高的并发和竞争情况，我更喜欢用synchronized，因为代码简洁，不容易出错。

不过，在讲这个之前，我得先吐槽一下：单例模式就像是单身狗的生活，看似简单，但一不小心就会出问题！比如，两个线程同时调用 getInstance()，都发现 instance 是 null，然后各自创建一个实例，结果就出现了两个单例对象。每次调用 getInstance() 都要加锁，但实际上只有在第一次创建实例时才需要加锁，后续的调用根本不需要锁。阳仔： 这个实现在大多数情况下是没问题的，但在某些极端情况下，可能会因为指令重排序而导致问题。它的核心思想是：先检查一次，如果实例不存在，再加锁创建实例。

java线程安全类介绍