java.util.concurrent.atomic原子操作类包

这个包里面提供了一组原子变量类。其基本的特性就是在多线程环境下,当有多个线程同时执行这些类的实例包含的方法时,具有排他性,即当某个线程进入方法,执行其中的指令时,不会被其他线程打断,而别的线程就像自旋锁一样,一直等到该方法执行完成,才由JVM从等待队列中选择一个另一个线程进入,这只是一种逻辑上的理解。实际上是借助硬件的相关指令来实现的,不会阻塞线程(或者说只是在硬件级别上阻塞了)。可以对基本数据、数组中的基本数据、对类中的基本数据进行操作。原子变量类相当于一种泛化的volatile变量,能够支持原子的和有条件的读-改-写操作。
    java.util.concurrent.atomic中的类可以分成4组:
标量类(Scalar):AtomicBoolean,AtomicInteger,AtomicLong,AtomicReference
数组类:AtomicIntegerArray,AtomicLongArray,AtomicReferenceArray
更新器类:AtomicLongFieldUpdater,AtomicIntegerFieldUpdater,AtomicReferenceFieldUpdater
复合变量类:AtomicMarkableReference,AtomicStampedReference
第一组AtomicBoolean,AtomicInteger,AtomicLong,AtomicReference这四种基本类型用来处理布尔,整数,长整数,对象四种数据,其内部实现不是简单的使用synchronized,而是一个更为高效的方式CAS (compare and swap) + volatile和native方法,从而避免了synchronized的高开销,执行效率大为提升。如AtomicInteger的实现片断为:
Java代码  收藏代码

private static final Unsafe unsafe = Unsafe.getUnsafe();  

private volatile int value;  

public final int get() {  

        return value;  

}  

public final void set(int newValue) {  

        value = newValue;  

}  

public final boolean compareAndSet(int expect, int update) {  

    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  

}

构造函数(两个构造函数)
默认的构造函数:初始化的数据分别是false,0,0,null
带参构造函数:参数为初始化的数据
set( )和get( )方法:可以原子地设定和获取atomic的数据。类似于volatile,保证数据会在主存中设置或读取
void set()和void lazySet():set设置为给定值,直接修改原始值;lazySet延时设置变量值,这个等价于set()方法,但是由于字段是volatile类型的,因此次字段的修改会比普通字段(非volatile字段)有稍微的性能延时(尽管可以忽略),所以如果不是想立即读取设置的新值,允许在“后台”修改值,那么此方法就很有用。
getAndSet( )方法
原子的将变量设定为新数据,同时返回先前的旧数据
其本质是get( )操作,然后做set( )操作。尽管这2个操作都是atomic,但是他们合并在一起的时候,就不是atomic。在Java的源程序的级别上,如果不依赖synchronized的机制来完成这个工作,是不可能的。只有依靠native方法才可以。
Java代码  收藏代码

public final int getAndSet(int newValue) {  

    for (;;) {  

        int current = get();  

        if (compareAndSet(current, newValue))  

            return current;  

    }  

}

compareAndSet( ) 和weakCompareAndSet( )方法
这 两个方法都是conditional modifier方法。这2个方法接受2个参数,一个是期望数据(expected),一个是新数据(new);如果atomic里面的数据和期望数据一 致,则将新数据设定给atomic的数据,返回true,表明成功;否则就不设定,并返回false。JSR规范中说:以原子方式读取和有条件地写入变量但不 创建任何 happen-before 排序,因此不提供与除 weakCompareAndSet 目标外任何变量以前或后续读取或写入操作有关的任何保证。大意就是说调用weakCompareAndSet时并不能保证不存在happen- before的发生(也就是可能存在指令重排序导致此操作失败)。但是从Java源码来看,其实此方法并没有实现JSR规范的要求,最后效果和 compareAndSet是等效的,都调用了unsafe.compareAndSwapInt()完成操作。
Java代码  收藏代码

public final boolean compareAndSet(int expect, int update) {  

    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  

}  

public final boolean weakCompareAndSet(int expect, int update) {  

    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);  

}

对于 AtomicInteger、AtomicLong还提供了一些特别的方法。
getAndIncrement( ):以原子方式将当前值加 1,相当于线程安全的i++操作。
incrementAndGet( ):以原子方式将当前值加 1, 相当于线程安全的++i操作。
getAndDecrement( ):以原子方式将当前值减 1, 相当于线程安全的i--操作。
decrementAndGet ( ):以原子方式将当前值减 1,相当于线程安全的--i操作。
addAndGet( ): 以原子方式将给定值与当前值相加, 实际上就是等于线程安全的i =i+delta操作。
getAndAdd( ):以原子方式将给定值与当前值相加, 相当于线程安全的t=i;i+=delta;return t;操作。
以实现一些加法,减法原子操作。(注意 --i、++i不是原子操作,其中包含有3个操作步骤:第一步,读取i;第二步,加1或减1;第三步:写回内存)
使用AtomicReference创建线程安全的堆栈
Java代码  收藏代码

package thread;  

import java.util.concurrent.atomic.AtomicReference;  

public class ConcurrentStack<T> {  

    private AtomicReference<Node<T>>    stacks  = new AtomicReference<Node<T>>();  

    public T push(T e) {  

        Node<T> oldNode, newNode;  

        for (;;) { // 这里的处理非常的特别,也是必须如此的。  

            oldNode = stacks.get();  

            newNode = new Node<T>(e, oldNode);  

            if (stacks.compareAndSet(oldNode, newNode)) {  

                return e;  

            }  

        }  

    }     

    public T pop() {  

        Node<T> oldNode, newNode;  

        for (;;) {  

            oldNode = stacks.get();  

            newNode = oldNode.next;  

            if (stacks.compareAndSet(oldNode, newNode)) {  

                return oldNode.object;  

            }  

        }  

    }     

    private static final class Node<T> {  

        private T       object;       

        private Node<T>   next;         

        private Node(T object, Node<T> next) {  

            this.object = object;  

            this.next = next;  

        }  

    }     

}

虽然原子的标量类扩展了Number类,但并没有扩展一些基本类型的包装类,如Integer或Long,事实上他们也不能扩展:基本类型的包装类是不可以修改的,而原子变量类是可以修改的。在原子变量类中没有重新定义hashCode或equals方法,每个实例都是不同的,他们也不宜用做基于散列容器中的键值。
      第二组AtomicIntegerArray,AtomicLongArray还有AtomicReferenceArray类进一步扩展了原子操作,对这些类型的数组提供了支持。这些类在为其数组元素提供 volatile 访问语义方面也引人注目,这对于普通数组来说是不受支持的。
他们内部并不是像AtomicInteger一样维持一个valatile变量,而是全部由native方法实现,如下
AtomicIntegerArray的实现片断:
Java代码  收藏代码

private static final Unsafe unsafe = Unsafe.getUnsafe();  

private static final int base = unsafe.arrayBaseOffset(int[].class);  

private static final int scale = unsafe.arrayIndexScale(int[].class);  

private final int[] array;  

public final int get(int i) {  

        return unsafe.getIntVolatile(array, rawIndex(i));  

}  

public final void set(int i, int newValue) {  

        unsafe.putIntVolatile(array, rawIndex(i), newValue);  

}

第三组AtomicLongFieldUpdater,AtomicIntegerFieldUpdater,AtomicReferenceFieldUpdater基于反射的实用工具,可以对指定类的指定 volatile 字段进行原子更新。API非常简单,但是也是有一些约束:
(1)字段必须是volatile类型的
(2)字段的描述类型(修饰符public/protected/default/private)是与调用者与操作对象字段的关系一致。也就是说 调用者能够直接操作对象字段,那么就可以反射进行原子操作。但是对于父类的字段,子类是不能直接操作的,尽管子类可以访问父类的字段。
(3)只能是实例变量,不能是类变量,也就是说不能加static关键字。
(4)只能是可修改变量,不能使final变量,因为final的语义就是不可修改。实际上final的语义和volatile是有冲突的,这两个关键字不能同时存在。
(5)对于AtomicIntegerFieldUpdater 和AtomicLongFieldUpdater 只能修改int/long类型的字段,不能修改其包装类型(Integer/Long)。如果要修改包装类型就需要使用AtomicReferenceFieldUpdater 。
 netty5.0中类ChannelOutboundBuffer统计发送的字节总数,由于使用volatile变量已经不能满足,所以使用AtomicIntegerFieldUpdater 来实现的,看下面代码:
Java代码  收藏代码

//定义  

    private static final AtomicLongFieldUpdater<ChannelOutboundBuffer> TOTAL_PENDING_SIZE_UPDATER =  

            AtomicLongFieldUpdater.newUpdater(ChannelOutboundBuffer.class, "totalPendingSize");  

  

    private volatile long totalPendingSize;  

  

  

  

//使用  

        long oldValue = totalPendingSize;  

        long newWriteBufferSize = oldValue + size;  

        while (!TOTAL_PENDING_SIZE_UPDATER.compareAndSet(this, oldValue, newWriteBufferSize)) {  

            oldValue = totalPendingSize;  

            newWriteBufferSize = oldValue + size;  

        }
时间: 2024-10-12 15:21:22

java.util.concurrent.atomic原子操作类包的相关文章

Java学习笔记—多线程(并发工具类,java.util.concurrent.atomic包)

在JDK的并发包里提供了几个非常有用的并发工具类.CountDownLatch.CyclicBarrier和Semaphore工具类提供了一种并发流程控制的手段,Exchanger工具类则提供了在线程间交换数据的一种手段.本章会配合一些应用场景来介绍如何使用这些工具类. CountDownLatch CountDownLatch允许一个或多个线程等待其他线程完成操作.假如有这样一个需求:我们需要解析一个Excel里多个sheet的数据,此时可以考虑使用多线程,每个线程解析一个sheet里的数据,

java.util.concurrent.atomic 包详解

Atomic包的作用: 方便程序员在多线程环境下,无锁的进行原子操作 Atomic包核心: Atomic包里的类基本都是使用Unsafe实现的包装类,核心操作是CAS原子操作 关于CAS compare and swap,比较和替换技术,将预期值与当前变量的值比较(compare),如果相等则使用新值替换(swap)当前变量,否则不作操作: 现代CPU已广泛支持CAS指令,如果不支持,那么JVM将使用自旋锁,与互斥锁一样,两者都需先获取锁才能访问共享资源,但互斥锁会导致线程进入睡眠,而自旋锁会一

《java.util.concurrent 包源码阅读》02 关于java.util.concurrent.atomic包

Aomic数据类型有四种类型:AomicBoolean, AomicInteger, AomicLong, 和AomicReferrence(针对Object的)以及它们的数组类型, 还有一个特殊的AomicStampedReferrence,它不是AomicReferrence的子类,而是利用AomicReferrence实现的一个储存引用和Integer组的扩展类 首先,所有原子操作都是依赖于sun.misc.Unsafe这个类,这个类底层是由C++实现的,利用指针来实现数据操作 关于CAS

Java学习笔记—多线程(原子类,java.util.concurrent.atomic包,转载)

原子类 Java从JDK 1.5开始提供了java.util.concurrent.atomic包(以下简称Atomic包),这个包中 的原子操作类提供了一种用法简单.性能高效.线程安全地更新一个变量的方式. 因为变量的类型有很多种,所以在Atomic包里一共提供了13个类,属于4种类型的原子更 新方式,分别是原子更新基本类型.原子更新数组.原子更新引用和原子更新属性(字段). Atomic包里的类基本都是使用Unsafe实现的包装类 java.util.concurrent.atomic中的类

关于java.util.concurrent.atomic.*包下面的线程问题

众所周知,jdk的java.util.concurrent.atomic包下得原子类都是线程安全的,这是正确的,但是如果如果这样设置变量,会出现什么问题呢: AtomicReference<Integer[]> ar = new AtomicReference<Integer[]>(); 可能结果不是你所想的是同步了,为什么会出现这种情况呢? 其实有一个很好的例子可以解释这个问题,大家都知道i++,这个自增的步骤就是读取旧值-->给这个值加1-->更新这个值散步组成,因

java.util.concurrent.atomic原理详解

十五年前,多处理器系统是高度专用系统,要花费数十万美元(大多数具有两个到四个处理器).现在,多处理器系统很便宜,而且数量很多,几乎每个主要微处理器都内置了多处理支持,其中许多系统支持数十个或数百个处理器. 要使用多处理器系统的功能,通常需要使用多线程构造应用程序.但是正如任何编写并发应用程序的人可以告诉你的那样,要获得好的硬件利用率,只是简单地在多个线程中分割工作是不够的,还必须确保线程确实大部分时间都在工作,而不是在等待更多的工作,或等待锁定共享数据结构. 问题:线程之间的协调 如果线程之间

聊聊高并发(十二)分析java.util.concurrent.atomic.AtomicStampedReference源码来看如何解决CAS的ABA问题

在聊聊高并发(十一)实现几种自旋锁(五)中使用了java.util.concurrent.atomic.AtomicStampedReference原子变量指向工作队列的队尾,为何使用AtomicStampedReference原子变量而不是使用AtomicReference是因为这个实现中等待队列的同一个节点具备不同的状态,而同一个节点会多次进出工作队列,这就有可能出现出现ABA问题. 熟悉并发编程的同学应该知道CAS操作存在ABA问题.我们先看下CAS操作. CAS(Compare and

java.util.concurrent.locks.Lock类的lock和lockInterruptibly方法的区别

什么是可中断的锁获取呢?就是:线程在等待获取锁的过程中,是否能够响应中断,以便在被中断的时候能够解除阻 塞状态,而不是傻傻地一直在等待.java对象的内置锁(synchronized)就是一种不可中断的锁,也就是说如果一个线 程在等待获取某个对象的内置锁,就算是该线程被其他线程中断,该线程仍然继续等待内置锁,而不是解除阻塞状 态,也不会抛出InterruptedException.Lock类的lock()类似synchronized,是不可中断的,在等待获取锁的过程中, 不响应中断请求:lock

java.util.concurrent.atomic 学习(二)

Aomic包下有四种数据类型: AomicBoolean, AomicInteger, AomicLong和AomicReferrence(针对Object的)以及它们的数组类型, 和相对应的AtomicXXXFieldUpdater. 各种数据类型中所有的原子操作都依赖于sun.misc.Unsafe这个类和CAS操作