登录/ 注册
 找回密码
 立即注册
关闭

CSDN热搜

程序园 精品问答 技术交流 资源下载
返回列表 发新帖
首页 › 业界区 › 业界 ›Java的volatile和sychronized底层实现

Java的volatile和sychronized底层实现

嗦或 5 天前
1. 概览

从Java代码级别到硬件级别各层都是如何实现的
1.png

2. Synchronized

2.1 字节码层面

使用javap -verbose 可以查看到字节码信息，其中synchronized方法会有flags:ACC_SYNCHRONIZED，此时字节码中不会包含monitorenter和moniotrexit，JVM会自动加
  1. public synchronized void syncMethod();
  2.   flags: ACC_PUBLIC, ACC_SYNCHRONIZED
复制代码
使用``javap -verbose `编译一个带synchronized块的代码可以看到字节码中的monitorenter和moniotrexit
  1. 0: new #2                  // 创建一个新的Object实例
  2. 3: dup
  3. 4: invokespecial #1        // 调用Object的构造函数
  4. 7: astore_1                // 将引用存储到局部变量1(lock)
  5. 8: aload_1                 // 将局部变量1(lock)加载到操作数栈
  6. 9: monitorenter            // 进入monitor
  7. 10: ...                    // 同步块体的字节码
  8.    : aload_1
  9.    : monitorexit           // 退出monitor
  10.    : ...
复制代码
2.2 JVM层面

源码可以在Github上面查看
monitorenter底层是由JVM的代码ObjectMonitor来实现的
  1. ObjectMonitor() {
  2.    // 多线程竞争锁进入时的单向链表
  3.    ObjectWaiter * volatile _cxq;
  4.    //处于等待锁block状态的线程，会被加入到该列表
  5.    ObjectWaiter * volatile _EntryList;
  6.    // _header是一个markOop类型，markOop就是对象头中的Mark Word
  7.    volatile markOop _header;
  8.    // 抢占该锁的线程数，约等于WaitSet.size + EntryList.size
  9.    volatile intptr_t _count;
  10.    // 等待线程数
  11.     volatile intptr_t _waiters;
  12.    // 锁的重入次数
  13.    volatile intptr_ _recursions;
  14.    // 监视器锁寄生的对象，锁是寄托存储于对象中
  15.    void* volatile  _object;
  16.    // 指向持有ObjectMonitor对象的线程
  17.    void* volatile _owner;
  18.    // 处于wait状态的线程，会被加入到_WaitSet
  19.    ObjectWaiter * volatile _WaitSet;
  20.    // 操作WaitSet链表的锁
  21.    volatile int _WaitSetLock;
  22.    // 嵌套加锁次数，最外层锁的_recursions属性为0
  23.    volatile intptr_t  _recursions;
  24. }
复制代码
2.2.1 enter方法

整个方法比较长，但我们了解的无锁、偏向锁、轻量级锁、重量级锁都可以看到，核心方法是Atomic::cmpxchg_ptr，这个是CAS操作
锁方法描述偏向锁Atomic::cmpxchg_ptr将owner替换为当前线程，成功则获取到锁轻量级锁TrySpin->Atomic::cmpxchg_ptr不断自旋将owner替换为当前线程，成功则获取到锁重量级锁EnterI>Atomic::cmpxchg_ptrpark然后将owner替换为当前线程，成功则获取到锁
  1. void ATTR ObjectMonitor::enter(TRAPS) {
  2.   // The following code is ordered to check the most common cases first
  3.   // and to reduce RTS->RTO cache line upgrades on SPARC and IA32 processors.
  4.   Thread * const Self = THREAD ;
  5.   void * cur ;
  6.   
  7.   // 无锁CAS 转为 偏向锁
  8.   cur = Atomic::cmpxchg_ptr (Self, &_owner, NULL) ;
  9.   if (cur == NULL) {
  10.      // Either ASSERT _recursions == 0 or explicitly set _recursions = 0.
  11.      assert (_recursions == 0   , "invariant") ;
  12.      assert (_owner      == Self, "invariant") ;
  13.      // CONSIDER: set or assert OwnerIsThread == 1
  14.      return ;
  15.   }
  16.        
  17.         // 可重入锁
  18.   if (cur == Self) {
  19.      // TODO-FIXME: check for integer overflow!  BUGID 6557169.
  20.      _recursions ++ ;
  21.      return ;
  22.   }
  23.        
  25.   if (Self->is_lock_owned ((address)cur)) {
  26.     assert (_recursions == 0, "internal state error");
  27.     _recursions = 1 ;
  28.     // Commute owner from a thread-specific on-stack BasicLockObject address to
  29.     // a full-fledged "Thread *".
  30.     _owner = Self ;
  31.     OwnerIsThread = 1 ;
  32.     return ;
  33.   }
  35.   // We've encountered genuine contention.
  36.   assert (Self->_Stalled == 0, "invariant") ;
  37.   Self->_Stalled = intptr_t(this) ;
  39.   // Try one round of spinning *before* enqueueing Self
  40.   // and before going through the awkward and expensive state
  41.   // transitions.  The following spin is strictly optional ...
  42.   // Note that if we acquire the monitor from an initial spin
  43.   // we forgo posting JVMTI events and firing DTRACE probes.
  44.   // 自旋获取锁
  45.   if (Knob_SpinEarly && TrySpin (Self) > 0) {
  46.      assert (_owner == Self      , "invariant") ;
  47.      assert (_recursions == 0    , "invariant") ;
  48.      assert (((oop)(object()))->mark() == markOopDesc::encode(this), "invariant") ;
  49.      Self->_Stalled = 0 ;
  50.      return ;
  51.   }
  53.   assert (_owner != Self          , "invariant") ;
  54.   assert (_succ  != Self          , "invariant") ;
  55.   assert (Self->is_Java_thread()  , "invariant") ;
  56.   JavaThread * jt = (JavaThread *) Self ;
  57.   assert (!SafepointSynchronize::is_at_safepoint(), "invariant") ;
  58.   assert (jt->thread_state() != _thread_blocked   , "invariant") ;
  59.   assert (this->object() != NULL  , "invariant") ;
  60.   assert (_count >= 0, "invariant") ;
  62.   // Prevent deflation at STW-time.  See deflate_idle_monitors() and is_busy().
  63.   // Ensure the object-monitor relationship remains stable while there's contention.
  64.   Atomic::inc_ptr(&_count);
  66.   EventJavaMonitorEnter event;
  68.   { // Change java thread status to indicate blocked on monitor enter.
  69.     JavaThreadBlockedOnMonitorEnterState jtbmes(jt, this);
  71.     DTRACE_MONITOR_PROBE(contended__enter, this, object(), jt);
  72.     if (JvmtiExport::should_post_monitor_contended_enter()) {
  73.       JvmtiExport::post_monitor_contended_enter(jt, this);
  74.     }
  76.     OSThreadContendState osts(Self->osthread());
  77.     ThreadBlockInVM tbivm(jt);
  79.     Self->set_current_pending_monitor(this);
  81.     // TODO-FIXME: change the following for(;;) loop to straight-line code.
  82.     for (;;) {
  83.       jt->set_suspend_equivalent();
  84.       // cleared by handle_special_suspend_equivalent_condition()
  85.       // or java_suspend_self()
  86.                        
  87.                         // 重量级锁
  88.       EnterI (THREAD) ;
  89.     省略.......
  90. }
复制代码
2.2.2 cmpxchg_ptr

上面的锁都用了这个方法cmpxchg_ptr，这个和java中的cas是类似的，那它又是怎么实现的呢
atomic源码
其中cmpxchg是Linux操作系统的函数，执行了一段汇编指令，并且有lock前缀
  1. // 多核心多cpu前面就要加lock
  2. #define LOCK_IF_MP(mp) "cmp $0, " #mp "; je 1f; lock; 1: "
  5. inline intptr_t Atomic::cmpxchg_ptr(intptr_t exchange_value, volatile intptr_t* dest, intptr_t compare_value) {
  6.   return (intptr_t)cmpxchg((jlong)exchange_value, (volatile jlong*)dest, (jlong)compare_value);
  7. }
  9. inline jlong    Atomic::cmpxchg    (jlong    exchange_value, volatile jlong*    dest, jlong    compare_value) {
  10.   bool mp = os::is_MP();
  11.   __asm__ __volatile__ (LOCK_IF_MP(%4) "cmpxchgq %1,(%3)"
  12.                         : "=a" (exchange_value)
  13.                         : "r" (exchange_value), "a" (compare_value), "r" (dest), "r" (mp)
  14.                         : "cc", "memory");
  15.   return exchange_value;
  16. }
复制代码
3. Volatile

3.1 字节码层面
  1.   static volatile int greaterThanSevenCnt;
  2.     descriptor: I
  3.     flags: ACC_STATIC, ACC_VOLATILE
复制代码
3.2 JVM层面

Github源码
可以看到判断是否是volatile字段，是的话最后会有OrderAccess::storeload(); , 就是就是storeload屏障
  1. CASE(_putfield):
  2. CASE(_putstatic):
  3.     {
  4.           // .... 省略若干行
  5.           // ....
  7.           // Now store the result 现在要开始存储结果了
  8.           // ConstantPoolCacheEntry* cache;     -- cache是常量池缓存实例
  9.           // cache->is_volatile()               -- 判断是否有volatile访问标志修饰
  10.           int field_offset = cache->f2_as_index();
  11.           if (cache->is_volatile()) { // ****重点判断逻辑****
  12.             // volatile变量的赋值逻辑
  13.             if (tos_type == itos) {
  14.               obj->release_int_field_put(field_offset, STACK_INT(-1));
  15.             } else if (tos_type == atos) {// 对象类型赋值
  16.               VERIFY_OOP(STACK_OBJECT(-1));
  17.               obj->release_obj_field_put(field_offset, STACK_OBJECT(-1));
  18.               OrderAccess::release_store(&BYTE_MAP_BASE[(uintptr_t)obj >> CardTableModRefBS::card_shift], 0);
  19.             } else if (tos_type == btos) {// byte类型赋值
  20.               obj->release_byte_field_put(field_offset, STACK_INT(-1));
  21.             } else if (tos_type == ltos) {// long类型赋值
  22.               obj->release_long_field_put(field_offset, STACK_LONG(-1));
  23.             } else if (tos_type == ctos) {// char类型赋值
  24.               obj->release_char_field_put(field_offset, STACK_INT(-1));
  25.             } else if (tos_type == stos) {// short类型赋值
  26.               obj->release_short_field_put(field_offset, STACK_INT(-1));
  27.             } else if (tos_type == ftos) {// float类型赋值
  28.               obj->release_float_field_put(field_offset, STACK_FLOAT(-1));
  29.             } else {// double类型赋值
  30.               obj->release_double_field_put(field_offset, STACK_DOUBLE(-1));
  31.             }
  32.             // *** 写完值后的storeload屏障 ***
  33.             OrderAccess::storeload();
  34.           } else {
  35.             // 非volatile变量的赋值逻辑
  36.             if (tos_type == itos) {
  37.               obj->int_field_put(field_offset, STACK_INT(-1));
  38.             } else if (tos_type == atos) {
  39.               VERIFY_OOP(STACK_OBJECT(-1));
  40.               obj->obj_field_put(field_offset, STACK_OBJECT(-1));
  41.               OrderAccess::release_store(&BYTE_MAP_BASE[(uintptr_t)obj >> CardTableModRefBS::card_shift], 0);
  42.             } else if (tos_type == btos) {
  43.               obj->byte_field_put(field_offset, STACK_INT(-1));
  44.             } else if (tos_type == ltos) {
  45.               obj->long_field_put(field_offset, STACK_LONG(-1));
  46.             } else if (tos_type == ctos) {
  47.               obj->char_field_put(field_offset, STACK_INT(-1));
  48.             } else if (tos_type == stos) {
  49.               obj->short_field_put(field_offset, STACK_INT(-1));
  50.             } else if (tos_type == ftos) {
  51.               obj->float_field_put(field_offset, STACK_FLOAT(-1));
  52.             } else {
  53.               obj->double_field_put(field_offset, STACK_DOUBLE(-1));
  54.             }
  55.           }
  56.           UPDATE_PC_AND_TOS_AND_CONTINUE(3, count);
  57.   }
复制代码
进入OrderAccess源码可以看到，直接执行了一段汇编指令，并且有lock前缀
  1. inline void OrderAccess::storeload()  { fence(); }
  2. inline void OrderAccess::fence() {
  3.   if (os::is_MP()) {
  4.     // always use locked addl since mfence is sometimes expensive
  5. #ifdef AMD64
  6.     __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
  7. #else
  8.     __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
  9. #endif
  10.   }
  11. }
复制代码
4. lock指令

在上面的分析中，最底层都设计到汇编层面的lock指令，这个指令有什么作用呢？
根据汇编参考文档IA-32 Assembly Language Reference Manual
The LOCK # signal is asserted during execution of the instruction following the lock prefix. This signal can be used in a multiprocessor system to ensure exclusive use of shared memory while LOCK # is asserted. The bts instruction is the read-modify-write sequence used to implement test-and-run. The lock prefix works only with the instructions listed here. If a lock prefix is used with any other instructions, an undefined opcode trap is generated.
Lock是一个指令前缀，用于多核处理器系统不使用共享内存
那么它又是怎么让其他核心不访问共享内存，有两种方法

  • 锁内存总线，也就是说执行这条指令的时候，其他的核心都不能在访问内存了
  • 锁缓存行，现在CPU本身是有多级缓存的，而这些缓存是如何保持一致的，由MESI来支持，MESI协议可以保证其他核心不使用内存，或者换一种说法，可以使用，但被修改的内容会失效
5. MESI协议

现代CPU多核架构中为了协调快速的CPU运算和相对较慢的内存读写速度之间的矛盾，在CPU和内存之间引入了CPU cache：
2.png

MESI协议下，缓存行(cache line)有四种状态来保证缓存的一致性

  • 已修改Modified (M) 缓存行是脏的，与主存的值不同。如果别的CPU内核要读主存这块数据，该缓存行必须回写到主存，状态变为共享(S)
  • 独占Exclusive (E) 缓存行只在当前缓存中，但是干净的（clean）–缓存数据同于主存数据。当别的缓存读取它时，状态变为共享；当前写数据时，变为已修改状态。
  • 共享Shared (S) 缓存行也存在于其它缓存中且是干净的。缓存行可以在任意时刻抛弃。
  • 无效Invalid (I) 缓存行是无效的，需要从主内存中读取最新值
每次要修改缓存，如果缓存行状态为 S 的话都要先发一个 invalidate 的广播，再等其他 CPU 将缓存行设置为无效后返回 invalidate ack 才能写到 Cache 中，因为这样才能保证缓存的一致性
但是如果 CPU 频繁地修改数据，就会不断地发送广播消息，CPU 只能被动同步地等待其他 CPU 的消息，显然会对执行效率产生影响
为了解决此问题，工程师在 CPU 和 cache 之间又加了一个 store buffer，同时在cache和总线之间添加了Invalidate Queue
这个buffer可以让广播和收广播的处理异步化，效率当然会变高，但强一致性变为了最终一致性
lock指令是CPU硬件工程师给程序员留的一个口子，把对MESI协议的优化(store buffer, invalidate queue)禁用，暂时以同步方式工作，使得对于该关键字的MESI协议退回强一致性状态
6. 总结

分析到此:
所有的并发问题可以概括为，多个核心同时修改内存数据，导致结果不符合预期
解决并发问题的方法可以概括为，同一时间只能让一个核心修改内存，但有多种手段，例如锁总线、或者广播让其他核心失效
7. 其他问题


  • 既然sychronized的和volatile底层实现是一样的，那么volatile为什么没有原子性呢？
    在于锁定的范围，volatile修饰的是一个字段，只能保证读和写是原子性的，但读出来、在计算、写入分为三步则不是原子性的。
    sychronized底层也用了volatile的，但它的锁定范围是程序员指定的，这个范围之间的代码是原子的
    1. cas volatile变量开始锁定
    2. 任意程序代码
    3. cas volatile变量释放锁定
    复制代码
  • 现在一般推荐使用Java的Atomic类，他是通过CAS来实现的，它和sychronized的区别是什么？
    cas不能单独使用，需要加自旋操作，本身是一个乐观锁
    sychronized本身结合了乐观锁和悲观锁，悲观锁会让线程park然后重试，不会消耗CPU，而乐观锁但不断消耗cpu
8. 对比

在阅读ObjectMonitor代码时，发现有很熟悉的感觉
3.png

发现这些锁的数据结果都是类似的，一个volatile变量加一个等待队列
参考

【1】]synchronized 关键字底层原理
【2】Java多线程：objectMonitor源码解读（3）
【3】Linux Kernel CMPXCHG函数分析
【4】聊聊CPU的LOCK指令
【5】12 张图看懂 CPU 缓存一致性与 MESI 协议，真的一致吗？
【6】MESI和volatile的关系详解
【7】volatile底层原理详解
【8】浅析mutex实现原理
【9】CAS你以为你真的懂？
【10】x86 LOCK 指令前缀
【11】Linux Mutex机制分析

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

使用道具 举报
相关推荐
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 立即注册
发帖
嗦或
5 天前

0

粉丝关注

8

主题发布

板块介绍填写区域，请于后台编辑
微信扫一扫