更多 Java 并发编程方面的文章,请参见文集《Java 并发编程》
摘要: 阿里巴巴集团推出的《阿里巴巴Java开发手册(正式版)》是阿里巴巴近万名开发同学集体智慧的结晶,以开发视角为中心,详细列举如何开发更加高效、更加容错、更加有协作性,力求知其然,更知其不然,结合正反例,让Java开发者能够提升协作效率、提高代码质量。
作为一个 Java 开发人员,我花了一天时间阅读了这个开发手册,摘要了一些对于我有用的知识点。记录如下,仅供参考。
并发处理
- 创建线程或线程池时请指定有意义的线程名称,方便出错时回溯。
public class TimerTaskThread extends Thread {
public TimerTaskThread(){
super.setName("TimerTaskThread"); ...
}
- 线程池不允许使用
Executors
去创建,而是通过ThreadPoolExecutor
的方式,这样的处理方式让写的同学更加明确线程池的运行规则,规避资源耗尽的风险。
说明:Executors
返回的线程池对象的弊端如下:
1)FixedThreadPool
和SingleThreadPool
:
允许的请求队列长度为Integer.MAX_VALUE
,可能会堆积大量的请求,从而导致 OOM。
2)CachedThreadPool
和ScheduledThreadPool
:
允许的创建线程数量为Integer.MAX_VALUE
,可能会创建大量的线程,从而导致 OOM。 - 高并发时,同步调用应该去考量锁的性能损耗。能用无锁数据结构,就不要用锁;能锁区块,就不要锁整个方法体;能用对象锁,就不要用类锁。
- 对多个资源、数据库表、对象同时加锁时,需要保持一致的加锁顺序,否则可能会造成死锁。
- 并发修改同一记录时,避免更新丢失,要么在应用层加锁,要么在缓存加锁,要么在数据库层使用乐观锁,使用 version 作为更新依据。
说明:如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次数不得小于 3 次。 - 使用
CountDownLatch
进行异步转同步操作,每个线程退出前必须调用countDown
方法,线程执行代码注意catch
异常,确保countDown
方法可以执行,避免主线程无法执行至countDown
方法,直到超时才返回结果。 - 避免
Random
实例被多线程使用,虽然共享该实例是线程安全的,但会因竞争同一seed
导致的性能下降。 - 通过双重检查锁(double-checked locking)(在并发场景)实现延迟初始化的优化问题隐患。
-
volatile
解决多线程内存不可见问题。对于一写多读,是可以解决变量同步问题,但是如果多写,同样无法解决线程安全问题。如果是count++
操作,使用如下类实现:
AtomicInteger count = new AtomicInteger(); count.addAndGet(1);
如果是 JDK8,推荐使用LongAdder
对象,比AtomicLong
性能更好(减少乐观锁的重试次数)。 -
HashMap
在容量不够进行resize
时由于高并发可能出现死链,导致 CPU 飙升,在开发过程中注意规避此风险。 -
ThreadLocal
无法解决共享对象的更新问题,ThreadLocal
对象建议使用static
修饰。这个变量是针对一个线程内所有操作共有的,所以设置为静态变量,所有此类实例共享此静态变量 ,也就是说在类第一次被使用时装载,只分配一块存储空间,所有此类的对象(只要是这个线程内定义的)都可以操控这个变量。