深入浅出 Java Concurrency (38): 并发总结 part 2 常见的并发场景[转]

常见的并发场景

线程池

并发最常见用于线程池,显然使用线程池可以有效的提高吞吐量。

最常见、比较复杂一个场景是Web容器的线程池。Web容器使用线程池同步或者异步处理HTTP请求,同时这也可以有效的复用HTTP连接,降低资源申请的开销。通常我们认为HTTP请求时非常昂贵的,并且也是比较耗费资源和性能的,所以线程池在这里就扮演了非常重要的角色。

线程池的章节中非常详细的讨论了线程池的原理和使用,同时也提到了,线程池的配置和参数对性能的影响是巨大的。不尽如此,受限于资源(机器的性能、网络的带宽等等)、依赖的服务,客户端的响应速度等,线程池的威力也不会一直增长。达到了线程池的瓶颈后,性能和吞吐量都会大幅度降低。

一直增加机器的性能或者增大线程的个数,并不一定能有效的提高吞吐量。高并发的情况下,机器的负载会大幅提升,这时候机器的稳定性、服务的可靠性都会下降。

尽管如此,线程池依然是提高吞吐量的一个有效措施,配合合适的参数能够有效的充分利用资源,提高资源的利用率。

 

任务队列

除了线程池是比较发杂的并发场景外,任务队列也是一个不错的并发工具。JDK内部有大量的队列(Queue),这些工具不仅能够方便使用,提高生产力,也能够进行组合适应于不同的场景。即使线程池内部,也是用了任务队列来处理任务的积压,平衡资源的消耗。

安全的任务队列能够有效的平衡机器的复杂,抵消由于峰值和波动带来的不稳定,有效提高服务的可靠性。同时任务队列的处理也有助于统计和分析服务的状况。

任务队列也可以在多个线程之间传递数据,有助于并行处理任务。例如经典的“生产者-消费者”模型就可以有效的提高多个线程的并行处理能力。在IO延时比较大的服务中尤其有效。 我最喜欢的一个案例是导数据是,一个线程负责往固定大小的任务队列中压入大量的数据,队列满了以后就暂停,另外几个线程负责从任务队列中获取数据并消费。这将串行的“生产-消费”,变成了并行的“生产-消费”。实践证明极大的节省任务处理时间。

 

异步处理

线程池也是异步处理的一种表现形式,除此之外,使用异步处理的目的也是为了提高服务的处理速度。 例如AOP的一个例子就是使用切面来记录日志,如果说我们要远程收集日志,显然不希望由于收集日志而影响服务本身。这时候就将日志收集的过程进行异步处理。

如今大量的开源组件都喜欢使用异步处理来提高IO的效率,某些不需要同步返回的操作使用异步处理后能够有效的提高吞吐量。

当然,异步也不总是令人满意的,也会有相应的问题。例如引入异步设计后的复杂性,线程中断后的处理机制,失败后的处理策略,产生的消息比消费的还快时怎么办,关闭程序时如何关闭异步处理逻辑等等。这都会增加系统的复杂性。

尽管大量的服务、业务使用异步来处理,但是很显然需要有保障机制能够保证异步处理的逻辑正确性。如果认为异步处理的任务不是特别重要,或者说主业务不能因为附属业务的逻辑出错而崩溃,那么使用异步处理是正确的选择。

 

同步操作

并发操作的同时还需要维护数据的一致性,或多或少的会涉及到同步操作。正确的使用原子操作,合理的使用独占锁和读写锁也是一个很大的挑战。

线程间的协调与通信,尤其是状态的同步都是比较困难的。我们看到线程池ThreadPoolExecutor的实现为了解决各个线程的执行状态,引入的很多的同步操作。线程越来越多的情况下,同步的成本会越来越高,同时也有可能引入死锁的情况。

尽管如此,单个JVM内部的多线程同步还是比较容易控制的。JDK内部也提供了大量的工具来方便完成数据的同步。例如Lock/Condition/CountDownLatch/CyclicBarrier/Semaphore/Exchanger等等。

 

分布式锁

分布式的并发问题更难以处理,根据CAP的原理,基本上没有一个至善至美的方案。 分布式资源协调使用分布式锁是一个不错的选择。Google的分布式锁(建立在BigTable之上),Zookeeper的分布式锁,甚至简单的利用memcache的add操作或者redis的setnx操作建立伪分布式锁也可以解决类似的问题。

    原文作者:java线程池
    原文地址: http://www.cnblogs.com/0x2D-0x22/p/4138818.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞