Atomic
從JDK5開始, java.util.concurrent包里提供了很多面向并發編程的類. 使用這些類在多核CPU的機器上會有比較好的性能.
主要原因是這些類里面大多使用(失敗-重試方式的)樂觀鎖而不是synchronized方式的悲觀鎖.
今天有時間跟蹤了一下AtomicInteger的incrementAndGet的實現.
本人對并發編程也不是特別了解, 在這里就是做個筆記, 方便以后再深入研究.
1. incrementAndGet的實現
首先可以看到他是通過一個無限循環(spin)直到increment成功為止.?
循環的內容是
1.取得當前值
2.計算+1后的值
3.如果當前值還有效(沒有被)的話設置那個+1后的值
4.如果設置沒成功(當前值已經無效了即被別的線程改過了), 再從1開始.
2. compareAndSet的實現
直接調用的是UnSafe這個類的compareAndSwapInt方法
全稱是sun.misc.Unsafe. 這個類是Oracle(Sun)提供的實現. 可以在別的公司的JDK里就不是這個類了
3. compareAndSwapInt的實現
可以看到, 不是用Java實現的, 而是通過JNI調用操作系統的原生程序.
4. compareAndSwapInt的native實現
如果你下載了OpenJDK的源代碼的話在hotspot\src\share\vm\prims\目錄下可以找到unsafe.cpp
可以看到實際上調用Atomic類的cmpxchg方法.
5. Atomic的cmpxchg
這個類的實現是跟操作系統有關, 跟CPU架構也有關, 如果是windows下x86的架構
實現在hotspot\src\os_cpu\windows_x86\vm\目錄的atomic_windows_x86.inline.hpp文件里
在這里可以看到是用嵌入的匯編實現的, 關鍵CPU指令是 cmpxchg
到這里沒法再往下找代碼了. 也就是說CAS的原子性實際上是CPU實現的. 其實在這一點上還是有排他鎖的. 只是比起用synchronized, 這里的排他時間要短的多. 所以在多線程情況下性能會比較好.
代碼里有個alternative?for?InterlockedCompareExchange
這個InterlockedCompareExchange是WINAPI里的一個函數, 做的事情和上面這段匯編是一樣的
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683560%28v=vs.85%29.aspx
6. 最后再貼一下x86的cmpxchg指定
CPU: I486+
Type of Instruction: User
Instruction: CMPXCHG dest, src
Description: Compares the accumulator with dest. If equal the "dest"
is loaded with "src", otherwise the accumulator is loaded
with "dest".
Flags Affected: AF, CF, OF, PF, SF, ZF
CPU mode: RM,PM,VM,SMM
+++++++++++++++++++++++
Clocks:
CMPXCHG reg, reg 6
CMPXCHG mem, reg 7 (10 if compartion fails)
?
主要原因是這些類里面大多使用(失敗-重試方式的)樂觀鎖而不是synchronized方式的悲觀鎖.
今天有時間跟蹤了一下AtomicInteger的incrementAndGet的實現.
本人對并發編程也不是特別了解, 在這里就是做個筆記, 方便以后再深入研究.
1. incrementAndGet的實現
????public?final?int?incrementAndGet()?{
????????for?(;;)?{
????????????int?current?=?get();
????????????int?next?=?current?+?1;
????????????if?(compareAndSet(current,?next))
????????????????return?next;
????????}
????}
????????for?(;;)?{
????????????int?current?=?get();
????????????int?next?=?current?+?1;
????????????if?(compareAndSet(current,?next))
????????????????return?next;
????????}
????}
首先可以看到他是通過一個無限循環(spin)直到increment成功為止.?
循環的內容是
1.取得當前值
2.計算+1后的值
3.如果當前值還有效(沒有被)的話設置那個+1后的值
4.如果設置沒成功(當前值已經無效了即被別的線程改過了), 再從1開始.
2. compareAndSet的實現
????public?final?boolean?compareAndSet(int?expect,?int?update)?{
????????return?unsafe.compareAndSwapInt(this,?valueOffset,?expect,?update);
????}
????????return?unsafe.compareAndSwapInt(this,?valueOffset,?expect,?update);
????}
直接調用的是UnSafe這個類的compareAndSwapInt方法
全稱是sun.misc.Unsafe. 這個類是Oracle(Sun)提供的實現. 可以在別的公司的JDK里就不是這個類了
3. compareAndSwapInt的實現
????/**
?????*?Atomically?update?Java?variable?to?<tt>x</tt>?if?it?is?currently
?????*?holding?<tt>expected</tt>.
?????*?@return?<tt>true</tt>?if?successful
?????*/
????public?final?native?boolean?compareAndSwapInt(Object?o,?long?offset,
??????????????????????????????????????????????????int?expected,
??????????????????????????????????????????????????int?x);
?????*?Atomically?update?Java?variable?to?<tt>x</tt>?if?it?is?currently
?????*?holding?<tt>expected</tt>.
?????*?@return?<tt>true</tt>?if?successful
?????*/
????public?final?native?boolean?compareAndSwapInt(Object?o,?long?offset,
??????????????????????????????????????????????????int?expected,
??????????????????????????????????????????????????int?x);
可以看到, 不是用Java實現的, 而是通過JNI調用操作系統的原生程序.
4. compareAndSwapInt的native實現
如果你下載了OpenJDK的源代碼的話在hotspot\src\share\vm\prims\目錄下可以找到unsafe.cpp
UNSAFE_ENTRY(jboolean,?Unsafe_CompareAndSwapInt(JNIEnv?*env,?jobject?unsafe,?jobject?obj,?jlong?offset,?jint?e,?jint?x))
??UnsafeWrapper("Unsafe_CompareAndSwapInt");
??oop?p?=?JNIHandles::resolve(obj);
??jint*?addr?=?(jint?*)?index_oop_from_field_offset_long(p,?offset);
??return?(jint)(Atomic::cmpxchg(x,?addr,?e))?==?e;
UNSAFE_END
??UnsafeWrapper("Unsafe_CompareAndSwapInt");
??oop?p?=?JNIHandles::resolve(obj);
??jint*?addr?=?(jint?*)?index_oop_from_field_offset_long(p,?offset);
??return?(jint)(Atomic::cmpxchg(x,?addr,?e))?==?e;
UNSAFE_END
可以看到實際上調用Atomic類的cmpxchg方法.
5. Atomic的cmpxchg
這個類的實現是跟操作系統有關, 跟CPU架構也有關, 如果是windows下x86的架構
實現在hotspot\src\os_cpu\windows_x86\vm\目錄的atomic_windows_x86.inline.hpp文件里
inline?jint?????Atomic::cmpxchg????(jint?????exchange_value,?volatile?jint*?????dest,?jint?????compare_value)?{
??//?alternative?for?InterlockedCompareExchange
??int?mp?=?os::is_MP();
??__asm?{
????mov?edx,?dest
????mov?ecx,?exchange_value
????mov?eax,?compare_value
????LOCK_IF_MP(mp)
????cmpxchg?dword?ptr?[edx],?ecx
??}
}
??//?alternative?for?InterlockedCompareExchange
??int?mp?=?os::is_MP();
??__asm?{
????mov?edx,?dest
????mov?ecx,?exchange_value
????mov?eax,?compare_value
????LOCK_IF_MP(mp)
????cmpxchg?dword?ptr?[edx],?ecx
??}
}
在這里可以看到是用嵌入的匯編實現的, 關鍵CPU指令是 cmpxchg
到這里沒法再往下找代碼了. 也就是說CAS的原子性實際上是CPU實現的. 其實在這一點上還是有排他鎖的. 只是比起用synchronized, 這里的排他時間要短的多. 所以在多線程情況下性能會比較好.
代碼里有個alternative?for?InterlockedCompareExchange
這個InterlockedCompareExchange是WINAPI里的一個函數, 做的事情和上面這段匯編是一樣的
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683560%28v=vs.85%29.aspx
6. 最后再貼一下x86的cmpxchg指定
Opcode CMPXCHG
CPU: I486+
Type of Instruction: User
Instruction: CMPXCHG dest, src
Description: Compares the accumulator with dest. If equal the "dest"
is loaded with "src", otherwise the accumulator is loaded
with "dest".
Flags Affected: AF, CF, OF, PF, SF, ZF
CPU mode: RM,PM,VM,SMM
+++++++++++++++++++++++
Clocks:
CMPXCHG reg, reg 6
CMPXCHG mem, reg 7 (10 if compartion fails)
?