第一章 并发编程的挑战
目的:让程序运行更快
并发编程面临的挑战:上下文切换、死锁、硬件和软件的资源限制
1.1 上下文切换
即使是单核处理器也支持多线程执行代码,CPU通过给每个线程分配CPU时间片来实现这个机制。时间片是CPU分配给各个线程的时间,因为时间片非常短,所以CPU通过不停地切换线程执行,让我们感觉多个线程是同时执行的,时间片一般是几十毫秒(ms)。
CPU通过时间片分配算法来循环执行任务,当前任务执行一个时间片后会切换到下一个任务。但是,在切换前会保存上一个任务的状态,以便下次切换回这个任务时,可以再加载这个任务的状态。所以任务从保存到再加载的过程就是一次上下文切换。
上下文切换,会影响到多线程的执行速度。
1.1.1 多线程一定快吗?
public class Test123 {
private static final long count = 100000000L;
public static void main(String[] args) throws InterruptedException {
concurrency();
seriala();
}
private static void seriala() {
long start = System.currentTimeMillis();
int a = 0;
for (long i = 0; i < count; i++) {
a += 5;
}
int b = 0;
for (long i = 0; i < count; i++) {
b--;
}
long time = System.currentTimeMillis() - start;
System.out.println("seriala:" + time + "ms,b=" + b + ",a=" + a);
}
private static void concurrency() throws InterruptedException {
long start = System.currentTimeMillis();
Thread thread = new Thread((new Runnable() {
@Override
public void run() {
int a = 0;
for (long i = 0; i < count; i++) {
a += 5;
}
}
}));
thread.start();
int b = 0;
for (long i = 0; i < count; i++) {
b--;
}
long time = System.currentTimeMillis() - start;
thread.join();
;
System.out.println("concurrency:" + time + "ms,b=" + b);
}
}
循环次数count | 串行执行耗时/ms | 并发耗时 | 并发比串行快多少 |
10亿 | 158 | 111 | |
1亿 | 118 | 81 | |
1千万 | 24 | 24 | |
1万 | 1 | 9 |
当并发执行不超过百万次时,速度会比串行执行累加操作要慢。因为线程有创建和上下文切换的开销。
1.1.2 测试上下文切换次数和时长
度量上下文切换带来的消耗:
使用Lmbench3可以测量上下文切换的时长。
使用vmstat可以测试上下文切换的次数。
下面是利用vmstat测量上下文切换次数的示例。
1.1.3 如何减少上下文切换
方法:无锁并发编程、CAS算法、使用最少线程、使用协程。
-无锁并发编程:多线程竞争锁时,会引起上下文切换,所以多线程处理数据时,可以用一些办法来避免使用锁,如将数据的ID按照Hash算法取模分段,不同的线程不同段的数据。
-CAS算法:Java的Atomic包使用CAS算法来更新数据,而不需要加锁。
比较并交换(Compare And Swap)参考 https://www.cnblogs.com/mjorcen/p/3966586.html
-使用最少线程:避免创建不需要的线程,比如任务很少,但是创建了很多线程来处理,这会造成大量线程处于等待状态。
-协程:在单线程里实现多任务的调度,并在单线程里维持多个任务间的切换。
1.1.4 减少上下文切换实战
通过减少线上大量WAITING的线程,来减少上下文切换次数。
(不懂)
第一步:用jstack命令dump线程信息、看看pid为3117的进程里的线程都在做什么。
第二步:统计所有线程分别处于什么状态,发现300多个线程处于WAITING(onobjectmonitor)状态。
第三步:打开dump文件查看处于WAITING(onobjectmonitor)的线程在做什么。发现线程基本是JBOSS的工作线程,在await。说明JBOSS线程池里线程接收到的任务太少,大量线程都闲着。
第四步:减少JBOSS的工作线程数,找到JBOSS的线程池配置信息,将maxThreads降到100.
第五步:重启JBOSS,再dump线程信息,然后统计WATING(onobjectmonitor)的线程,发现减少了175个。
每一次从WAITING到RUNNING都会进行一次上下文切换。
1.2 死锁
1.2.1 出现死锁的情况:(面试遇到)
拿到锁后因为一些异常情况没有释放锁(死循环);
拿到数据库锁,释放时抛出异常,没有释放掉。
一旦出现死锁,业务可感知。只能通过dump线程查看到底是哪个线程出现问题。(不懂,怎么查看)
1.2.2 避免死锁的方法:
(1)避免一个线程同时获取多个锁;
(2)避免一个线程在锁内同时占用多个资源,尽量保证每个锁只占用一个资源;
(疑问:一个方法内,启用2个future属于占用几个资源?跟这个有关?--无关)
public static final ExecutorService c = new ThreadPoolExecutor(10, 10, 1L, TimeUnit.MILLISECONDS, new SynchronousQueue<>(), new ThreadFactoryBuilder().setNameFormat("XXXX ").build(), new ThreadPoolExecutor.CallerRunsPolicy());
CompletableFuture<Integer> a = new CompletableFuture<>();
CompletableFuture<Integer> b = new CompletableFuture<>();
c.execute(() ->
{
try {
a.complete(XXXXXXX);
} catch (Exception e) { }
});
c.execute(() ->
{
try {
b.complete(XXXXX);
} catch (Exception e) {
}
});
(3)尝试使用定时锁,使用lock.tryLock(timeout)来替代使用内部锁机制。
(4)对于数据库锁,加锁和解锁必须在一个数据库连接里,否则会出现解锁失败的情况。(疑问:集群的情况,多个服务部署多个ip,多个数据库连接,会出现解锁失败?怎么规避?)
1.3 资源限制的挑战
1.3.1 什么是资源限制
资源限制是指在进行并发编程时,程序的执行速度受限于计算机硬件资源或软件资源。
例如,服务器的带宽只有2Mb/s,某个资源的下载速度是1Mb/s,系统启动10个线程下载资源,下载速度不会变成10Mb/s,所以在并发编程时,要考虑资源的限制。硬件资源的限制有带宽的上传/下载速度、硬盘读写速度和CPU处理速度。软件资源的限制有数据库的链接数和socket链接数等。
1.3.2 资源限制引发的问题
在并发编程中,将代码执行速度加快的原则是将代码中串行执行的部分变成并发执行。但是,如果将某段串行的代码并发执行,因为受限于资源,仍然在串行执行,这时程序会更慢,因为增加了上下文切换和资源调度的时间。
例如,一段程序使用多线程在办公网并发地下载和处理数据时,导致CPU利用率达到100%,几个小时都不能运行完成任务,改成单线程慢慢执行,1个小时就完了。
1.3.3 如何解决资源限制的问题
对于硬件资源限制,可以考虑使用集群并行执行程序。既然单机的资源有限制,就让程序在多机上运行。比如ODPS、Hadoop或自己搭建服务器集群,不同的机器处理不同的数据。
对于软件资源的限制,可以考虑使用资源池将资源复用。比如使用连接池将数据库和Socket连接复用,或在调用对方webservice接口获取数据时,只建立一个连接。
1.3.4 在资源限制情况下进行并发编程
根据不同的资源限制调整程序的并发度,比如下载文件程序依赖于2个资源——带宽和硬盘读写速度。有数据库操作时,涉及数据库连接数,如果SQL语句执行非常快,而线程的数量比数据库连接数大很多,则某些线程会被阻塞,等待数据库连接。
1.4 本章小结
本章介绍了并发编程时,可能会遇到的挑战,以及解决建议。
建议多使用JDK并发包提供的并发容器和工具类。