标签：account 框架 Account final AtomicReferenceFieldUpdater atomic new public

一、什么是FieldUpdater

在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 increMoney() {
        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.increMoney();         // 增加账户金额
        }
    }
}

上述未对Account做并发控制，最终账户金额很可能小于100。按照之前学习的atomic框架，可以将Account类的int类型字段改为AtomicInteger或者在Task任务类中，将所有涉及到共享变量的地方都加锁访问。

那么，还有没有其它解决方式？

本章开头我们讲到，AtomicXXXFieldUpdater可以以一种线程安全的方式操作非线程安全对象的某些字段。
这里，Account就是非线程安全对象，money就是需要操作的字段。

我们来对上述代码进行改造：
账户类Account改造：

class Account {
    private volatile int money;
    private static final AtomicIntegerFieldUpdater<Account> updater = AtomicIntegerFieldUpdater.newUpdater(Account.class, "money");  // 引入AtomicIntegerFieldUpdater

    Account(int initial) {
        this.money = initial;
    }

    public void increMoney() {
        updater.incrementAndGet(this);    // 通过AtomicIntegerFieldUpdater操作字段
    }

    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);

        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.increMoney();
        }
    }
}

上述代码，无论执行多少次，最终结果都是100，因为这回是线程安全的。

对比下改造，可以发现，AtomicIntegerFiledUpdater的引入，使得我们可以在不修改用户代码（调用方）的情况下，就能实现并发安全性。

唯一的改变之处就是Account内部的改造：

private static final AtomicIntegerFieldUpdater<Account> updater = AtomicIntegerFieldUpdater.newUpdater(Account.class, "money");  // 引入AtomicIntegerFieldUpdater
updater.incrementAndGet(this);

这也是AtomicXXXFieldUpdater引入的一个重要原因，单纯从功能上来讲，能用AtomicXXXFieldUpdater实现的并发控制，同步器和其它原子类都能实现，但是使用AtomicXXXFieldUpdater，符合面向对象设计的一个基本原则——开闭原则，尤其是对一些遗留代码的改造上。

另外，使用AtomicXXXFieldUpdater，不需要进行任何同步处理，单纯的使用CAS+自旋操作就可以实现同步的效果。这也是整个atomic包的设计理念之一。

二、 AtomicXXXFieldUpdater

2.1 应用场景

AtomicXXXFieldUpdater这个在代码中不经常会有，但是有时候可以作为性能优化的工具出场，一般在下面两种情况会使用它：

• 你想通过正常的引用使用volatile的，比如直接在类中调用this.variable,但是你也想时不时的使用一下CAS操作或者原子自增操作，那么你可以使用fieldUpdater。
• 当你使用AtomicXXX的时候，其引用Atomic的对象有多个的时候，你可以使用fieldUpdater节约内存开销。

为什么有了AtomicLong还要使用AtomicLongFieldUpdater？
因为当需要进行原子限定的属性所属的类会被创建大量的实例对象,如果用AtomicLong每个实例里面都要创建AtomicLong对象,从而多出内存消耗,显然是不合适的。因此出现了AtomicLongFieldUpdater（原子字段更新器），仅需要在抽象的父类中声明一个静态的更新器，就可以在各个对象中使用了。

2.2 正常引用volatile变量

一般有两种情况需要正常引用：

1. 当代码中引入已经正常引用，但是这个时候需要新增一个CAS的需求，我们可以将其替换AtomicXXX对象，但是之前的调用都得换成.get()和.set()方法，这样做会增加不少的工作量，并且还需要大量的回归测试。
2. 代码更加容易理解，在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.3 节约内存

在很多开源框架中都能看见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节约了大量内存

JdbcSqlStat.java

三、AtomicReferenceFieldUpdater原理

AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdater这三个类大同小异，AtomicIntegerFieldUpdater只能处理int原始类型的字段，AtomicLongFieldUpdater只能处理long原始类型的字段，AtomicReferenceFieldUpdater可以处理所有引用类型的字段。

本节以AtomicReferenceFieldUpdater为例，介绍下FiledUpdater的基本原理。

3.1 AtomicReferenceFieldUpdater对象的创建

AtomicReferenceFieldUpdater本身是一个抽象类，没有公开的构造器，只能通过静态方法newUpdater创建一个AtomicReferenceFieldUpdater子类对象：

newUpdater的三个入参含义如下：

入参名称	含义
tclass	目标对象的类型
vclass	目标字段的类型
fieldName	目标字段名

AtomicReferenceFieldUpdaterImpl是AtomicReferenceFieldUpdater的一个内部类，并继承了AtomicReferenceFieldUpdater。AtomicReferenceFieldUpdater的API，基本都是委托AtomicReferenceFieldUpdaterImpl来实现的。

来看下AtomicReferenceFieldUpdaterImpl对象的构造，其实就是一系列的权限检查：

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);
}

通过源码，可以看到AtomicReferenceFieldUpdater的使用必须满足以下条件：

1. AtomicReferenceFieldUpdater只能修改对于它可见的字段，也就是说对于目标类的某个字段field，如果修饰符是private，但是AtomicReferenceFieldUpdater所在的使用类不能看到field，那就会报错；
2. 目标类的操作字段，必须用volatile修饰；
3. 目标类的操作字段，不能是static的；
4. AtomicReferenceFieldUpdater只适用于引用类型的字段；

3.2 AtomicReferenceFieldUpdater的方法原理

AtomicReferenceFieldUpdater中所有的方法都是基于Unsafe类操作，看下最常用的方法compareAndSet：

public final boolean compareAndSet(T obj, V expect, V update) {
    accessCheck(obj);
    valueCheck(update);
    return U.compareAndSwapObject(obj, offset, expect, update);
}

通过偏移量offset获取字段的地址，然后利用Unsafe进行CAS更新。其它方法也大同小异，读者可以参考Oracle官方文档和JDK源码。

标签：account,框架,Account,final,AtomicReferenceFieldUpdater,atomic,new,public
来源： https://www.cnblogs.com/ciel717/p/16190556.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。