锁 - 共享数据安全指↑
内容提要
文章续述MESI协议中Store Buffer与Invalid Queue优化会导致可见性延迟和内存顺序不一致，需用内存屏障恢复；高级语言以volatile封装屏障语义，C/C++与Java实现不同。原子性由总线锁或缓存锁保障，自旋锁基于lock;xchg实现，并衍生信号量、互斥锁、synchronized、CAS无锁等；锁同时处理有序性与可见性，应控制锁粒度并优选数据结构。
延伸解读
从硬件到语言：理解锁的底层逻辑
文章指出，共享数据不安全源于原子性、可见性和有序性三大问题，分别对应单核时间片、多核缓存和编译器优化。锁作为解决方案，底层依赖硬件原子指令（如xchg、cmpxchg）和内存屏障。高级语言如Java的volatile封装了屏障语义，但C/C++与Java实现不同。理解这些物理原因，有助于选择适合业务场景的锁，避免盲目加锁。
MESI优化与内存屏障的权衡
MESI协议通过状态机维护缓存一致性，但Store Buffer和Invalid Queue的引入虽提升了性能，却导致可见性延迟和内存顺序不一致。内存屏障能恢复顺序，但会牺牲部分性能。文章强调，屏障应仅在共享数据不安全处添加，而非全局使用。高级语言通过volatile等机制简化了屏障的使用，但开发者仍需理解其代价。
自旋锁：高效但需谨慎使用
自旋锁基于lock; xchg指令实现，是其他锁的基石。它通过循环尝试获取锁，响应速度快，但会持续消耗CPU。文章指出，自旋锁适用于临界区执行时间极短的场景，否则CPU空转严重。操作系统和高级语言在自旋锁基础上增加了睡眠队列、优先级调整等机制，衍生出信号量、互斥锁等，以平衡效率与资源消耗。
锁的粒度与数据结构优化
锁在解决原子性的同时，也处理了有序性和可见性，但容易成为性能瓶颈。文章建议控制锁的粒度，仅保护必要的共享数据，并优选高效的数据结构。例如，YYCache使用互斥锁和LRU算法（双向链表+哈希表）将操作复杂度降至O(1)。在并发场景下，除了选择高效的锁，优化数据结构和算法同样关键。
Q&A
为什么多核CPU下原子指令（如cmpxchg）不再安全？
在单核下，原子指令执行期间不会被打断，因此是安全的。但在多核并行场景下，一个核心执行cmpxchg时，另一个核心可能同时修改同一内存地址的值，导致比较和交换的结果不符合预期，从而破坏数据安全。
MESI协议中的Store Buffer和Invalid Queue优化会导致什么问题？
Store Buffer和Invalid Queue优化将写操作和失效处理异步化，提高了CPU效率，但会导致缓存可见性延迟和内存顺序不一致。例如，一个核心的写操作可能不会立即被其他核心看到，且写操作的顺序可能与其他核心观察到的顺序不同，从而引发数据安全问题。
内存屏障是如何解决MESI优化带来的问题的？
内存屏障通过强制清空Store Buffer和Invalid Queue，使MESI优化暂时失效，从而恢复缓存一致性和顺序一致性。读屏障处理Invalid Queue，写屏障处理Store Buffer，全屏障则两者都处理。屏障会牺牲一定性能，但确保了共享数据的安全。
C/C++和Java中的volatile关键字在内存语义上有何不同？
在C/C++中，volatile主要告知编译器不要优化，并在变量访问前后插入内存屏障，确保可见性。Java中的volatile除了禁止重排序和插入内存屏障外，还通过JMM的Happens-before语义和四种内存屏障（LoadLoad、LoadStore、StoreStore、StoreLoad）来保证可见性和有序性，具体实现依赖硬件架构。
自旋锁是如何实现的？它有什么优缺点？
自旋锁基于原子交换指令（如xchg）实现，通过循环尝试获取锁。优点是响应速度快，因为等待线程不断轮询，锁释放后能立即获取；缺点是消耗CPU资源，在锁竞争激烈时可能导致CPU空转，因此适用于临界区执行时间极短的场景。
什么是双重检查锁？为什么需要volatile？
双重检查锁是一种单例模式优化，通过两次检查实例是否为空来减少锁的开销。但实例化操作可能因指令重排序导致其他线程获取到未初始化完成的对象，因此需要用volatile修饰实例变量，禁止重排序，确保安全。
