Java原子类之AtomicReferenceFieldUpdater源码分析
一、简介
在java.util.concurrent.atomic包中，由三个比较特殊的原子类：AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdater。
通过名称可以看到，这几类的功能大致相同，只是针对的类型有所不同。所谓AtomicXXXFieldUpdater，是基于反射的实用工具，可以对指定类的指定volatile字段进行原子更新，这个类设计用于在原子数据结构中，对同一个节点的几个字段独立的进行原子性更新。简单来说就是可以以一种线程安全的方式操作非线程安全对象的某些字段。
光这么说有点难理解，我们通过一个例子来看下。
假设有一个公司账户Account，100个人同时往里面存钱1块钱，那么正常情况下，最终账户的总金额应该是100。
先来看下线程不安全的方式：
账户类：
class Account {
private volatile int money;
Account(int initial) {
this.money = initial;
}
public void incrMoney() {
money++;
}
public int getMoney() {
return money;
}
@Override
public String toString() {
return "Account{" + "money=" + money + '}';
}
}
调用类：
public class FieldUpdaterTest {
public static void main(String[] args) throws InterruptedException {
Account account = new Account(0); // 初始金额0
List<Thread> list = new ArrayList<>();
for (int i = 0; i < 100; i++) {
Thread t = new Thread(new Task(account));
list.add(t);
t.start();
}
for (Thread t : list) { // 等待所有线程执行完成
t.join();
}
System.out.println(account.toString());
}
private static class Task implements Runnable {
private Account account;
Task(Account account) {
this.account = account;
}
@Override
public void run() {
account.incrMoney(); // 增加账户金额
}
}
}
上述未对Account做并发控制，最终账户金额很可能小于100。按照之前学习的atomic框架，可以将Account类的int类型字段改为AtomicInteger或者在Task任务类中，将所有涉及到共享变量的地方都加锁访问。
那么，还有没有其它解决方式？
本章开头我们讲到，AtomicXXXFieldUpdater可以以一种线程安全的方式操作非线程安全对象的某些字段。
这里，Account就是非线程安全对象，money就是需要操作的字段。
我们来对上述代码进行改造：账户类Account改造：
class Account {
private volatile int money;
// 引入AtomicIntegerFieldUpdater
private static final AtomicIntegerFieldUpdater<Account> updater =
AtomicIntegerFieldUpdater.newUpdater(Account.class, "money");
Account(int initial) {
this.money = initial;
}
public void incrMoney() {
updater.incrementAndGet(this); // 通过AtomicIntegerFieldUpdater操作字段
}
public int getMoney() {
return money;
}
@Override
public String toString() {
return "Account{" + "money=" + money + '}';
}
}
调用方，并未做任何改变
上述代码，无论执行多少次，最终结果都是100，因为这回是线程安全的。
对比下改造，可以发现，AtomicIntegerFiledUpdater的引入，使得我们可以在不修改用户代码（调用方）的情况下，就能实现并发安全性。
唯一的改变之处就是Account内部的改造：
// 引入AtomicIntegerFieldUpdater
private static final AtomicIntegerFieldUpdater<Account> updater
= AtomicIntegerFieldUpdater.newUpdater(Account.class, "money");
updater.incrementAndGet(this);
这也是AtomicXXXFieldUpdater引入的一个重要原因，单纯从功能上来讲，能用AtomicXXXFieldUpdater实现的并发控制，同步器和其它原子类都能实现，但是使用AtomicXXXFieldUpdater，符合面向对象设计的一个基本原则——开闭原则，尤其是对一些遗留代码的改造上。
另外，使用AtomicXXXFieldUpdater，不需要进行任何同步处理，单纯的使用CAS+自旋操作就可以实现同步的效果。这也是整个atomic包的设计理念之一。
二、应用场景
AtomicXXXFieldUpdater这个在代码中不经常会有，但是有时候可以作为性能优化的工具出场，一般在下面两种情况会使用它：
- 你想通过正常的引用使用volatile的，比如直接在类中调用this.variable,但是你也想时不时的使用一下CAS操作或者原子自增操作，那么你可以使用fieldUpdater。
- 当你使用AtomicXXX的时候，其引用Atomic的对象有多个的时候，你可以使用fieldUpdater节约内存开销。
为什么有了AtomicLong还要使用AtomicLongFieldUpdater？
因为当需要进行原子限定的属性所属的类会被创建大量的实例对象，如果用AtomicLong每个实例里面都要创建AtomicLong对象，从而多出内存消耗，显然是不合适的。因此出现了AtomicLongFieldUpdater（原子字段更新器），仅需要在抽象的父类中声明一个静态的更新器，就可以在各个对象中使用了。
2.1 正常引用volatile变量
一般有两种情况需要正常引用：
- 当代码中引入已经正常引用，但是这个时候需要新增一个
CAS的需求，我们可以将其替换AtomicXXX对象，但是之前的调用都得换成.get()和.set()方法，这样做会增加不少的工作量，并且还需要大量的回归测试。 - 代码更加容易理解，在
BufferedInputStream中，有一个buf数组用来表示内部缓冲区，它也是一个volatile数组，在BufferedInputStream中大多数时候只需要正常的使用这个数组缓冲区即可，在一些特殊的情况下，比如close的时候需要使用compareAndSet，我们可以使用AtomicReference，我觉得这样做有点乱，使用fieldUpdater来说更加容易理解，
protected volatile byte buf[];
private static final AtomicReferenceFieldUpdater<BufferedInputStream, byte[]> bufUpdater =
AtomicReferenceFieldUpdater.newUpdater(BufferedInputStream.class, byte[].class, "buf");
public void close() throws IOException {
byte[] buffer;
while ( (buffer = buf) != null) {
if (bufUpdater.compareAndSet(this, buffer, null)) {
InputStream input = in;
in = null;
if (input != null)
input.close();
return;
}
// Else retry in case a new buf was CASed in fill()
}
}
2.2 节约内存
在很多开源框架中都能看见fieldUpdater的身影，其实大部分的情况都是为了节约内存，为什么其会节约内存呢？首先来看看AtomicInteger类:
public class AtomicInteger extends Number implements java.io.Serializable {
private static final long serialVersionUID = 6214790243416807050L;
// setup to use Unsafe.compareAndSwapInt for updates
private static final Unsafe unsafe = Unsafe.getUnsafe();
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
private volatile int value;
}
在AtomicInteger成员变量只有一个int value，似乎好像并没有多出内存，但是我们的AtomicInteger是一个对象，一个对象的正确计算应该是对象头 + 数据大小，在64位机器上AtomicInteger对象占用内存如下：
- 关闭指针压缩：16(对象头) + 4(实例数据) = 20不是8的倍数，因此需要对齐填充16 + 4 + 4(padding) = 24
- 开启指针压缩（-XX:+UseCompressedOop)：12 + 4 = 16已经是8的倍数了，不需要再padding。
由于我们的AtomicInteger是一个对象，还需要被引用，那么真实的占用为：
- 关闭指针压缩：24 + 8 = 32
- 开启指针压缩：16 + 4 = 20
而fieldUpdater是static final类型并不会占用我们对象的内存，所以使用fieldUpdater的话可以近似认为只用了4字节，这个再未关闭指针压缩的情况下节约了7倍，关闭的情况下节约了4倍，这个在少量对象的情况下可能不明显，当我们对象有几十万，几百万，或者几千万的时候，节约的可能就是几十M,几百M,甚至几个G。
比如在netty中的AbstractReferenceCountedByteBuf，netty是自己管理内存的，所有的ByteBuf都会继承AbstractReferenceCountedByteBuf，在netty中ByteBuf会被大量的创建，netty使用fieldUpdater用于节约内存。
在阿里开源的数据库连接池druid中也有同样的体现，早在2012的一个pr中，就有优化内存的comment。
统计数据对象，这些对象通常会以秒级创建，分钟级创建新的，druid通过fieldUpdater节约了大量内存
三、源码分析
AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdater这三个类大同小异，AtomicIntegerFieldUpdater只能处理int原始类型的字段，AtomicLongFieldUpdater只能处理long原始类型的字段，AtomicReferenceFieldUpdater可以处理所有引用类型的字段。
3.1 对象的创建
AtomicReferenceFieldUpdater本身是一个抽象类，没有公开的构造器，只能通过静态方法newUpdater创建一个AtomicReferenceFieldUpdater子类对象。
public abstract class AtomicReferenceFieldUpdater<T,V> {
/**
* 定义工厂方法，构建AtomicReferenceFieldUpdater
* @param tclass 目标对象的类型
* @param vclass 目标字段的类型
* @param fieldName 目标字段名
* @param <U>
* @param <W>
* @return
*/
@CallerSensitive
public static <U,W> AtomicReferenceFieldUpdater<U,W> newUpdater(Class<U> tclass,
Class<W> vclass,
String fieldName) {
return new AtomicReferenceFieldUpdaterImpl<U,W>
(tclass, vclass, fieldName, Reflection.getCallerClass());
}
//构造方法
protected AtomicReferenceFieldUpdater() {
}
//cas更新
public abstract boolean compareAndSet(T obj, V expect, V update);
public abstract boolean weakCompareAndSet(T obj, V expect, V update);
public abstract void set(T obj, V newValue);
public abstract void lazySet(T obj, V newValue);
public abstract V get(T obj);
public V getAndSet(T obj, V newValue) {
V prev;
do {
prev = get(obj);
} while (!compareAndSet(obj, prev, newValue));
return prev;
}
public final V getAndUpdate(T obj, UnaryOperator<V> updateFunction) {
V prev, next;
do {
prev = get(obj);
next = updateFunction.apply(prev);
} while (!compareAndSet(obj, prev, next));
return prev;
}
public final V updateAndGet(T obj, UnaryOperator<V> updateFunction) {
V prev, next;
do {
prev = get(obj);
next = updateFunction.apply(prev);
} while (!compareAndSet(obj, prev, next));
return next;
}
public final V getAndAccumulate(T obj, V x,
BinaryOperator<V> accumulatorFunction) {
V prev, next;
do {
prev = get(obj);
next = accumulatorFunction.apply(prev, x);
} while (!compareAndSet(obj, prev, next));
return prev;
}
public final V accumulateAndGet(T obj, V x,
BinaryOperator<V> accumulatorFunction) {
V prev, next;
do {
prev = get(obj);
next = accumulatorFunction.apply(prev, x);
} while (!compareAndSet(obj, prev, next));
return next;
}
private static final class AtomicReferenceFieldUpdaterImpl<T,V>
extends AtomicReferenceFieldUpdater<T,V> {
}
}
3.2 内部类
AtomicReferenceFieldUpdaterImpl是AtomicReferenceFieldUpdater的一个内部类，并继承了AtomicReferenceFieldUpdater。AtomicReferenceFieldUpdater的API，基本都是委托AtomicReferenceFieldUpdaterImpl来实现的。
来看下AtomicReferenceFieldUpdaterImpl对象的构造，其实就是一系列的权限检查：
private static final class AtomicReferenceFieldUpdaterImpl<T,V>
extends AtomicReferenceFieldUpdater<T,V> {
//使用Unsafe做CAS操作
private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();
private final long offset;
/**
* 待更新的的对象的类的Class对象
*/
private final Class<?> cclass;
/** 待操作的目标对象 */
private final Class<T> tclass;
/** 待操作的字段的类型 */
private final Class<V> vclass;
AtomicReferenceFieldUpdaterImpl(final Class<T> tclass,
final Class<V> vclass,
final String fieldName,
final Class<?> caller) {
final Field field;
final Class<?> fieldClass;
final int modifiers;
try {
// 获取要更新的类的指定成员变量fieldName的访问策略
field = AccessController.doPrivileged(
new PrivilegedExceptionAction<Field>() {
public Field run() throws NoSuchFieldException {
return tclass.getDeclaredField(fieldName);
}
});
// 判断调用方是否可以访问字段(其实就是对字段修饰符的上下文判断)
modifiers = field.getModifiers();
// 验证访问策略
sun.reflect.misc.ReflectUtil.ensureMemberAccess(
caller, tclass, null, modifiers);
// 目标类的类加载器
ClassLoader cl = tclass.getClassLoader();
// 调用类的类加载器
ClassLoader ccl = caller.getClassLoader();
if ((ccl != null) && (ccl != cl) &&
((cl == null) || !isAncestor(cl, ccl))) {
// 检查包访问权限
sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass);
}
// 当前成员变量的类型
fieldClass = field.getType();
} catch (PrivilegedActionException pae) {
throw new RuntimeException(pae.getException());
} catch (Exception ex) {
throw new RuntimeException(ex);
}
if (vclass != fieldClass)
throw new ClassCastException();
if (vclass.isPrimitive())
throw new IllegalArgumentException("Must be reference type");
// 当前成员变量必须是volatile修饰
if (!Modifier.isVolatile(modifiers))
throw new IllegalArgumentException("Must be volatile type");
// 设置调用者类
this.cclass = (Modifier.isProtected(modifiers) &&
tclass.isAssignableFrom(caller) &&
!isSamePackage(tclass, caller))
? caller : tclass;
// 设置目标操作类
this.tclass = tclass;
this.vclass = vclass;
// 设置成员变量的内存偏移值
this.offset = U.objectFieldOffset(field);
}
//判断第二个类加载器是否能在第一个加载器委托链中找到
private static boolean isAncestor(ClassLoader first, ClassLoader second) {
ClassLoader acl = first;
do {
acl = acl.getParent();
if (second == acl) {
return true;
}
} while (acl != null);
return false;
}
//判断两个classes是否是相同的类加载器和包修饰
private static boolean isSamePackage(Class<?> class1, Class<?> class2) {
return class1.getClassLoader() == class2.getClassLoader()
&& Objects.equals(getPackageName(class1), getPackageName(class2));
}
private static String getPackageName(Class<?> cls) {
String cn = cls.getName();
int dot = cn.lastIndexOf('.');
return (dot != -1) ? cn.substring(0, dot) : "";
}
//判断目标参数是否obj的实例
private final void accessCheck(T obj) {
if (!cclass.isInstance(obj))
throwAccessCheckException(obj);
}
private final void throwAccessCheckException(T obj) {
if (cclass == tclass)
throw new ClassCastException();
else
throw new RuntimeException(
new IllegalAccessException(
"Class " +
cclass.getName() +
" can not access a protected member of class " +
tclass.getName() +
" using an instance of " +
obj.getClass().getName()));
}
private final void valueCheck(V v) {
if (v != null && !(vclass.isInstance(v)))
throwCCE();
}
static void throwCCE() {
throw new ClassCastException();
}
//原子更新
public final boolean compareAndSet(T obj, V expect, V update) {
accessCheck(obj);
valueCheck(update);
return U.compareAndSwapObject(obj, offset, expect, update);
}
public final boolean weakCompareAndSet(T obj, V expect, V update) {
// same implementation as strong form for now
accessCheck(obj);
valueCheck(update);
return U.compareAndSwapObject(obj, offset, expect, update);
}
public final void set(T obj, V newValue) {
accessCheck(obj);
valueCheck(newValue);
U.putObjectVolatile(obj, offset, newValue);
}
public final void lazySet(T obj, V newValue) {
accessCheck(obj);
valueCheck(newValue);
U.putOrderedObject(obj, offset, newValue);
}
@SuppressWarnings("unchecked")
public final V get(T obj) {
accessCheck(obj);
return (V)U.getObjectVolatile(obj, offset);
}
@SuppressWarnings("unchecked")
public final V getAndSet(T obj, V newValue) {
accessCheck(obj);
valueCheck(newValue);
return (V)U.getAndSetObject(obj, offset, newValue);
}
}
通过源码，可以看到AtomicReferenceFieldUpdater的使用必须满足以下条件：
AtomicReferenceFieldUpdater只能修改对于它可见的字段，也就是说对于目标类的某个字段field，如果修饰符是private，但是AtomicReferenceFieldUpdater所在的使用类不能看到field，那就会报错；- 目标类的操作字段，必须用
volatile修饰； - 目标类的操作字段，不能是
static的； AtomicReferenceFieldUpdater只适用于引用类型的字段；
AtomicReferenceFieldUpdater中所有的方法都是基于Unsafe类操作，最常用的方法compareAndSet，通过偏移量offset获取字段的地址，然后利用Unsafe进行CAS更新。其它方法也大同小异。
