当前位置: 首页 > 编程笔记 >

Java 高并发十: JDK8对并发的新支持详解

景俊语
2023-03-14
本文向大家介绍Java 高并发十: JDK8对并发的新支持详解,包括了Java 高并发十: JDK8对并发的新支持详解的使用技巧和注意事项,需要的朋友参考一下

1. LongAdder

和AtomicLong类似的使用方式,但是性能比AtomicLong更好。

LongAdder与AtomicLong都是使用了原子操作来提高性能。但是LongAdder在AtomicLong的基础上进行了热点分离,热点分离类似于有锁操作中的减小锁粒度,将一个锁分离成若干个锁来提高性能。在无锁中,也可以用类似的方式来增加CAS的成功率,从而提高性能。

LongAdder原理图:

AtomicLong的实现方式是内部有个value 变量,当多线程并发自增,自减时,均通过CAS 指令从机器指令级别操作保证并发的原子性。唯一会制约AtomicLong高效的原因是高并发,高并发意味着CAS的失败几率更高, 重试次数更多,越多线程重试,CAS失败几率又越高,变成恶性循环,AtomicLong效率降低。

而LongAdder将把一个value拆分成若干cell,把所有cell加起来,就是value。所以对LongAdder进行加减操作,只需要对不同的cell来操作,不同的线程对不同的cell进行CAS操作,CAS的成功率当然高了(试想一下3+2+1=6,一个线程3+1,另一个线程2+1,最后是8,LongAdder没有乘法除法的API)。

可是在并发数不是很高的情况,拆分成若干的cell,还需要维护cell和求和,效率不如AtomicLong的实现。LongAdder用了巧妙的办法来解决了这个问题。

初始情况,LongAdder与AtomicLong是相同的,只有在CAS失败时,才会将value拆分成cell,每失败一次,都会增加cell的数量,这样在低并发时,同样高效,在高并发时,这种“自适应”的处理方式,达到一定cell数量后,CAS将不会失败,效率大大提高。

LongAdder是一种以空间换时间的策略。

2. CompletableFuture

实现CompletionStage接口(40余个方法),大多数方法多数应用在函数式编程中。并且支持流式调用

CompletableFuture是Java 8中对Future的增强版

简单实现:

import java.util.concurrent.CompletableFuture;

public class AskThread implements Runnable {
 CompletableFuture<Integer> re = null;

 public AskThread(CompletableFuture<Integer> re) {
 this.re = re;
 }

 @Override
 public void run() {
 int myRe = 0;
 try {
 myRe = re.get() * re.get();
 } catch (Exception e) {
 }
 System.out.println(myRe);
 }

 public static void main(String[] args) throws InterruptedException {
 final CompletableFuture<Integer> future = new CompletableFuture<Integer>();
 new Thread(new AskThread(future)).start();
 // 模拟长时间的计算过程
 Thread.sleep(1000);
 // 告知完成结果
 future.complete(60);
 }
}

Future最令人诟病的就是要等待,要自己去检查任务是否完成了,在Future中,任务完成的时间是不可控的。而 CompletableFuture的最大改进在于,任务完成的时间也开放了出来。

future.complete(60);

用来设置完成时间。

CompletableFuture的异步执行:

public static Integer calc(Integer para) {
 try {
 // 模拟一个长时间的执行
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 }
 return para * para;
 }

 public static void main(String[] args) throws InterruptedException,
 ExecutionException {
 final CompletableFuture<Integer> future = CompletableFuture
 .supplyAsync(() -> calc(50));
 System.out.println(future.get());
 }
CompletableFuture的流式调用:

public static Integer calc(Integer para) {
 try {
 // 模拟一个长时间的执行
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 }
 return para * para;
 }

 public static void main(String[] args) throws InterruptedException,
 ExecutionException {
 CompletableFuture<Void> fu = CompletableFuture
 .supplyAsync(() -> calc(50))
 .thenApply((i) -> Integer.toString(i))
 .thenApply((str) -> "\"" + str + "\"")
 .thenAccept(System.out::println);
 fu.get();
 }

组合多个CompletableFuture:

public static Integer calc(Integer para) {
 return para / 2;
 }

 public static void main(String[] args) throws InterruptedException,
 ExecutionException {
 CompletableFuture<Void> fu = CompletableFuture
 .supplyAsync(() -> calc(50))
 .thenCompose(
  (i) -> CompletableFuture.supplyAsync(() -> calc(i)))
 .thenApply((str) -> "\"" + str + "\"")
 .thenAccept(System.out::println);
 fu.get();
 }

这几个例子更多是侧重Java8的一些新特性,这里就简单举下例子来说明特性,就不深究了。
CompletableFuture跟性能上关系不大,更多的是为了支持函数式编程,在功能上的增强。当然开放了完成时间的设置是一大亮点。

3. StampedLock

在上一篇中刚刚提到了锁分离,而锁分离的重要的实现就是ReadWriteLock。而StampedLock则是ReadWriteLock的一个改进。StampedLock与ReadWriteLock的区别在于,StampedLock认为读不应阻塞写,StampedLock认为当读写互斥的时候,读应该是重读,而不是不让写线程写。这样的设计解决了读多写少时,使用ReadWriteLock会产生写线程饥饿现象。

所以StampedLock是一种偏向于写线程的改进。

StampedLock示例:

import java.util.concurrent.locks.StampedLock;

public class Point {
 private double x, y;
 private final StampedLock sl = new StampedLock();

 void move(double deltaX, double deltaY) { // an exclusively locked method
 long stamp = sl.writeLock();
 try {
 x += deltaX;
 y += deltaY;
 } finally {
 sl.unlockWrite(stamp);
 }
 }

 double distanceFromOrigin() { // A read-only method
 long stamp = sl.tryOptimisticRead();
 double currentX = x, currentY = y;
 if (!sl.validate(stamp)) {
 stamp = sl.readLock();
 try {
 currentX = x;
 currentY = y;
 } finally {
 sl.unlockRead(stamp);
 }
 }
 return Math.sqrt(currentX * currentX + currentY * currentY);
 }
}

上述代码模拟了写线程和读线程, StampedLock根据stamp来查看是否互斥,写一次stamp变增加某个值

tryOptimisticRead()

就是刚刚所说的读写不互斥的情况。

每次读线程要读时,会先判断

if (!sl.validate(stamp))

validate中会先查看是否有写线程在写,然后再判断输入的值和当前的 stamp是否相同,即判断是否读线程将读到最新的数据。

如果有写线程在写,或者 stamp数值不同,则返回失败。

如果判断失败,当然可以重复的尝试去读,在示例代码中,并没有让其重复尝试读,而采用的是将乐观锁退化成普通的读锁去读,这种情况就是一种悲观的读法。

stamp = sl.readLock();

StampedLock的实现思想:

CLH自旋锁:当锁申请失败时,不会立即将读线程挂起,在锁当中会维护一个等待线程队列,所有申请锁,但是没有成功的线程都记录在这个队列中。每一个节点(一个节点代表一个线程),保存一个标记位(locked),用于判断当前线程是否已经释放锁。当一个线程试图获得锁时,取得当前等待队列的尾部节点作为其前序节点。并使用类似如下代码判断前序节点是否已经成功释放锁

while (pred.locked) {  
}

这个循环就是不断等前面那个结点释放锁,这样的自旋使得当前线程不会被操作系统挂起,从而提高了性能。
当然不会进行无休止的自旋,会在若干次自旋后挂起线程。

 类似资料:
  • 摘要: 本系列基于炼数成金课程,为了更好的学习,做了系列的记录。 本文主要介绍: 1. LongAdder 2. CompletableFuture 3. StampedLock 1. LongAdder 和AtomicLong类似的使用方式,但是性能比AtomicLong更好。 LongAdder与AtomicLong都是使用了原子操作来提高性能。但是LongAdder在AtomicLong的基

  • 高级并发对象 目前为止,之前的教程都是重点讲述了最初作为 Java 平台一部分的低级别 API。这些API 对于非常基本的任务来说已经足够,但是对于更高级的任务就需要更高级的 API。特别是针对充分利用了当今多处理器和多核系统的大规模并发应用程序。 本章,我们将着眼于 Java 5.0 新增的一些高级并发特征。大多数功能已经在新的java.util.concurrent 包中实现。Java 集合框

  • 问题内容: 我正在多线程环境中通过不同的并发模型(http://tutorials.jenkov.com/java-concurrency/concurrency- models.html ) 本文重点介绍了 三种并发 模型。 平行工人 第一个并发模型是我所说的并行工作器模型。进来的工作分配给不同的 工人 。 流水线 工人的组织就像 工厂 中装配线的工人一样。每个工人仅完成全部工作的一部分。完成该

  • 并发概念太模糊,这里以两种可以量化的指标并发连接数和并发请求数来说明。 并发连接数是指服务器当前时刻一共维持了多少TCP连接,而这些连接上是否有数据通讯并不关注,例如一台消息推送服务器上可能维持了百万的设备连接,由于连接上很少有数据通讯,所以这台服务器上负载可能几乎为0,只要内存足够,还可以继续接受连接。 并发请求数一般用QPS(服务器每秒处理多少请求)来衡量,而当前时刻服务器上有多少个tcp连接

  • 本文向大家介绍Hadoop高并发?相关面试题,主要包含被问及Hadoop高并发?时的应答技巧和注意事项,需要的朋友参考一下 首先肯定要保证集群的高可靠性,在高并发的情况下不会挂掉,支撑不住可以通过横向扩展。 datanode挂掉了使用hadoop脚本重新启动。

  • 考虑以下方法: 尤其是这两条线: 如果线程A进入synchronized块并获得当前对象的锁,这是否意味着该对象的实例属性的状态不能被synchronized块之外的其他线程改变(当线程A在synchronized块中时)? 例如,线程A执行了第1行- 消息是非静态同步列表 UPD:更新的方法,可能的解决方案: addLock - AtomicBoolean,默认为false