java.util.concurrent(JUC)的研究--》atomic原子操作--》从AtomicInteger开始

通常情况下,在Java里面,++i或者--i不是线程安全的,这里面有三个独立的操作:读变量当前值,为该值+1/-1,然后写回新的值。在没有额外资源可以利用的情况下,只能使用加锁才能保证读-改-写这三个操作时“原子性”的。

在concurrent包未引进之前,是采用synchronized并且在变量上使用了volatile来实现的。

public final synchronized void set(int newValue);

public final synchronized int getAndSet(int newValue);

public final synchronized int incrementAndGet();

下面我们以AtomicInteger为例来分析下:

int addAndGet(int delta)
          以原子方式将给定值与当前值相加。 实际上就是等于线程安全版本的i =i+delta操作。

int decrementAndGet()
          以原子方式将当前值减 1。 相当于线程安全版本的--i操作。

int incrementAndGet()
          以原子方式将当前值加 1。 相当于线程安全版本的++i操作。

int getAndAdd(int delta)
          以原子方式将给定值与当前值相加。 相当于线程安全版本的t=i;i+=delta;return t;操作。

int getAndDecrement()
          以原子方式将当前值减 1。 相当于线程安全版本的i--操作。

int getAndIncrement()
          以原子方式将当前值加 1。 相当于线程安全版本的i++操作。

int getAndSet(int newValue)
          以原子方式设置为给定值,并返回旧值。 相当于线程安全版本的t=i;i=newValue;return t;操作。

boolean compareAndSet(int expect, int update)
          如果当前值 == 预期值,则以原子方式将该值设置为给定的更新值。 如果成功就返回true,否则返回false,并且不修改原值。

void lazySet(int newValue)
          最后设置为给定值。 延时设置变量值,这个等价于set()方法,但是由于字段是volatile类型的,因此次字段的修改会比普通字段(非volatile字段)有稍微的性能延时(尽管可以忽略),所以如果不是想立即读取设置的新值,允许在“后台”修改值,那么此方法就很有用。如果还是难以理解,这里就类似于启动一个后台线程如执行修改新值的任务,原线程就不等待修改结果立即返回(这种解释其实是不正确的,但是可以这么理解)。

void set(int newValue)
          设置为给定值。 直接修改原始值,也就是i=newValue操作。

boolean weakCompareAndSet(int expect, int update)
          如果当前值 == 预期值,则以原子方式将该设置为给定的更新值。JSR规范中说:以原子方式读取和有条件地写入变量但 创建任何 happen-before 排序,因此不提供与除weakCompareAndSet 目标外任何变量以前或后续读取或写入操作有关的任何保证。大意就是说调用weakCompareAndSet时并不能保证不存在happen-before的发生(也就是可能存在指令重排序导致此操作失败)。但是从Java源码来看,其实此方法并没有实现JSR规范的要求,最后效果和compareAndSet是等效的,都调用了unsafe.compareAndSwapInt()完成操作。

 

### Java多线程中的死锁产生条件 死锁是指两个或多个线程互相持有对方所需要的资源,从而导致这些线程都处于等待状态而无法继续执行的情况。Java中死锁产生的必要条件有四个: 1. **互斥条件**:至少有一个资源必须以非共享模式被占用,即一次只有一个线程能使用该资源。 2. **占有并请求(Hold and Wait)**:一个线程已经持有了某些资源,同时又申请新的资源。 3. **不可剥夺(No Preemption)**:已分配的资源不能强制从进程手中抢夺,只有主动释放。 4. **循环等待(Circular Wait)**:存在一组线程{Ti},其中每个线程Ti都在等待T(i+1)所占有的资源,形成闭环。 以上四者缺一不可[^1]。 --- ### `i++` 操作的线程安全性分析 在多线程环境中,看似简单的自增操作 `i++` 实际上并不是原子性的。它实际上由三个独立的操作组成: 1. 获取变量 `i` 的当前值; 2. 将其加 1; 3. 把新值写回内存。 由于这三个步骤并非作为一个整体完成,因此当多个线程同时对同一个变量执行 `i++` 操作时,可能会因为上下文切换而导致数据不一致的问题。例如,假设初始值为 0,两个线程分别读取到相同的旧值 0 并各自将其增加至 1 后再写入,则最终结果可能仍然是 1 而不是预期的 2[^3]。 为了保证此类操作在线程间的正确性和一致性,可以采用同步机制或者借助于 JUC 提供的一些高级工具来替代传统的手动锁定方法。 --- ### 使用 `java.util.concurrent.atomic` 解决 `i++` 非线程安全问题 针对上述提到的传统方式下存在的隐患,我们可以引入 `java.util.concurrent.atomic` 包下的类来进行优化处理。比如对于整数型计数器场景来说,推荐使用 `AtomicInteger` 类代替普通的 int 变量定义形式。下面给出一段基于此概念改造后的代码实例展示如何确保每次递增动作都能可靠地被执行而不受干扰影响: ```java import java.util.concurrent.atomic.AtomicInteger; public class SafeCounter { private AtomicInteger counter = new AtomicInteger(0); public void increment() { counter.incrementAndGet(); } public int getValue() { return counter.get(); } } ``` 这里运用到了之前提及过的 CAS (Compare And Swap) 原理,使得即便是在高度竞争环境下也能维持良好的性能表现的同时保障数值更新过程的安全性。 --- ### 关于线程池的应用补充说明 虽然本题重点讨论的是关于死锁预防以及单个变量操作上的注意事项,但值得一提的是,在实际开发过程中合理配置和应用好现成框架所提供的功能模块同样重要。正如前面有所涉及那样,通过恰当选用不同种类别的 ExecutorService 来调度任务队列长度控制等方面均有助于进一步降低潜在风险发生概率提升程序稳定性[^4]。 --- ####
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值