[Java9] Variable Handles

개요

java.util.concurrent.atomic이나 sun.misc.Unsafe을 이용하여 값들을 읽기/쓰기 했었는데, 보다 일관적인 방법을 제공한다.

목적

• 안정성:  유효한 메모리 바운더리안에서 사용
• 무결정: final 필드 값을 업데이트 할 수 없음
• 성능: sun.misc.Unsafe보다 성능이 비슷하거나 좋음
• 사용성: sun.misc.Unsafe API, java.util.concurrent.atomic API보다 사용하기 좋음

자극

  자바에서 동시 및 병렬 프로그래밍이 할 일이 많아졌다. counter 값을 원자적으로(thread safe하게) 변경 하기 위해서는 AtomicInteger(공간문제나 추가 작업등으로 오버헤드가 큼)나 sun.misc.Unsafe API(안전하지 않고 이식성이 안좋음)을 사용해야 했다. 이런 원자적인 값을 다루는 데 일관된 사용에 편리함을 줄 것이다.

설명

• variable handle은 다양한 access mode에서 변수에 대한 읽기/쓰기를 제공하는 참조(reference)
• 대상: instance field, static field, array, off-heap regions(ByteBuffers) ...
• library enhancements, JVM enhancements, compiler support가 필요함

Memory Ordering

Memory Ordering	Access	Description
plain	read/write	레퍼런스와 32bit 이하의 원시자료형 값에 대해서만 atomic함
volatile	read/write	메모리에서 데이터를 읽고 씀
opaque	read/write	같은 변수들에 대해서만 atomic함
acquire	read	이 액세스 전에 후속 로드 및 저장소의 순서가 변경되지 않음
release	write	이 액세스 후 이전 로드 및 저장소의 순서가 변경되지 않음

C/C++11의 atomic와 대응됨

Memory Fence Methods

Method	Operations Before Fence	Operations After Fence
void fullFence()	loads and stores	loads and stores
void acquireFence()	loads	loads and stores
void releaseFence()	loads and stores	stores
void loadLoadFence()	loads	loads
void storeStoreFence()	stores	stores

C/C++11의 atomic_thread_fence와 대응됨

코드

같이 알면 좋은 지식들

• volatile
• 자바의 volatile 키워드는 무슨 의미일까...
• USING THE VOLATILE KEYWORD IN JAVA
• memory ordering
• Memory ordering
• memory barrier
• Memory Barriers and JVM Concurrency
• Memory Barriers/Fences
• cuncurrency/parallel programming
• Java Concurrency / Multithreading Tutorial

관련된 한글 자료가 없어서 힘들다...

참고

• Exploring Java 9
• http://openjdk.java.net/jeps/193
• https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/VarHandle.html
• https://www.voxxed.com/2016/11/java-9-series-variable-handles/
• http://www.baeldung.com/java-variable-handles
• http://parkcheolu.tistory.com/16
• http://kwanseob.blogspot.kr/2012/08/java-volatile.html
• https://en.wikipedia.org/wiki/Memory_ordering
• http://shinluckyarchive.tistory.com/237