现有业务场景需要做一个线程间的全局变量,并且实现自增效果。
初始使用了volatile 来保证count的安全性,如下:
import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class TestThredd { private volatile int count = 0; public void increment() { count++; } private int getCount() { return count; } /** * 这里模拟一个递增的任务,递增目标为50000 */ public static void main(String[] args) throws InterruptedException { final TestThredd counter = new TestThredd(); int workCount = 50000; ExecutorService executor = Executors.newFixedThreadPool(10); long start = System.currentTimeMillis(); for (int i = 0; i < workCount; i++) { Runnable runnable = new Runnable() { @Override public void run() { counter.increment(); } }; executor.execute(runnable); } // 关闭启动线程,执行未完成的任务 executor.shutdown(); // 等待所有线程完成任务,完成后才继续执行下一步 executor.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS); System.out.println("耗时:" + (System.currentTimeMillis() - start) + "ms"); System.out.println("执行结果:count=" + counter.getCount()); } }
执行结果
它的结果不是我们预料的50000 .通常我们需要加上在count++时 加上synchronized关键字,保证他的正确性。
如下:
import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; public class TestThredd { private volatile int count = 0; /** * 为了保证数据的准确性,多线程的情况下需要加上synchronized关键字 * 否则会出现出乎预料的结果 这也是线程安全的重要体现 */ public synchronized void increment() { count++; } private int getCount() { return count; } /** * 这里模拟一个递增的任务,递增目标为50000 */ public static void main(String[] args) throws InterruptedException { final TestThredd counter = new TestThredd(); int workCount = 50000; ExecutorService executor = Executors.newFixedThreadPool(10); long start = System.currentTimeMillis(); for (int i = 0; i < workCount; i++) { Runnable runnable = new Runnable() { @Override public void run() { counter.increment(); } }; executor.execute(runnable); } // 关闭启动线程,执行未完成的任务 executor.shutdown(); // 等待所有线程完成任务,完成后才继续执行下一步 executor.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS); System.out.println("耗时:" + (System.currentTimeMillis() - start) + "ms"); System.out.println("执行结果:count=" + counter.getCount()); } }
为了保证数据的准确性,多线程的情况下需要加上synchronized关键字,否则会出现不安全的操作
如果我们换个方式,用AtomicInteger来替换count++,怎么做呢?
import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicInteger; public class AtomicCounter { private AtomicInteger count = new AtomicInteger(0); // 使用AtomicInteger之后,不需要加锁,也可以实现线程安全。 public void increment() { //获取当前的值并自增 count.incrementAndGet(); } /** * 获取当前的值 * @return */ public int getCount() { return count.get(); } //递减 public void deIncrement(){ count.decrementAndGet(); } /** * 这里模拟一个递增的任务,递增目标为50000 */ public static void main(String[] args) throws InterruptedException { final AtomicCounter counter = new AtomicCounter(); int workCount = 50000; ExecutorService executor = Executors.newFixedThreadPool(10); long start = System.currentTimeMillis(); for (int i = 0; i < workCount; i++) { Runnable runnable = new Runnable() { @Override public void run() { counter.increment(); } }; executor.execute(runnable); } // 关闭启动线程,执行未完成的任务 executor.shutdown(); // 等待所有线程完成任务,完成后才继续执行下一步 executor.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS); System.out.println("耗时:" + (System.currentTimeMillis() - start) + "ms"); System.out.println("执行结果:count=" + counter.getCount()); } }
AtomicInteger很轻松的实现了线程安全的变量操作
Java从JDK 1.5开始提供了java.util.concurrent.atomic包(以下简称Atomic包),这个包中的原子操作类提供了一种用法简单、性能高效、线程安全地更新一个变量的方式。因为变量的类型有很多种,所以在Atomic包里一共提供了13个类,属于4种类型的原子更新方式,分别是原子更新基本类型、原子更新数组、原子更新引用和原子更新属性(字段)。Atomic包里的类基本都是使用Unsafe实现的包装类。
使用原子的方式更新基本类型,Atomic包提供了以下3个类。
AtomicBoolean:原子更新布尔类型。
AtomicInteger:原子更新整型。
AtomicLong:原子更新长整型。
通过原子的方式更新数组里的某个元素,Atomic包提供了以3类
AtomicIntegerArray:原子更新整型数组里的元素。
AtomicLongArray:原子更新长整型数组里的元素。
AtomicReferenceArray:原子更新引用类型数组里的元素。
AtomicInteger是一个提供原子操作的Integer类,通过线程安全的方式操作加减。
AtomicInteger是在使用非阻塞算法实现并发控制,在一些高并发程序中非常适合,但并不能每一种场景都适合,不同场景要使用使用不同的数值类。
这是由硬件提供原子操作指令实现的,这里面用到了一种并发技术:CAS。在非激烈竞争的情况下,开销更小,速度更快。
参考:
http://blog.csdn.net/sunxianghuang/article/details/52277370
http://blog.csdn.net/u012734441/article/details/51619751
http://blog.csdn.net/jan_s/article/details/47025095