设计模式Java并发？并发安全

▌ 技术引导 在Java并发编程中，设计模式是避免数据竞争和线程安全问题的核心手段。我见过太多人因为没用同步机制直接操作共享资源，导致系统崩溃或者数据混乱。正确的做法是，针对不同的业务场景选择合适的并发安全设计模式。比如，使用ReentrantLock比synchronized更灵活，但对性能有影响。同步容器如Vector、Hashtable虽然安全，但效率低下，适合小数据量的场景。而并发容器如ConcurrentHashMap、CopyOnWriteArrayList则在高并发下表现更稳定。我踩过的坑包括在多线程环境中直接修改集合结构，结果导致死锁或数据丢失。所以，必须明确每种设计模式的适用边界，避免误用。 我在实际项目中用过单例模式结合双重检查锁定，这种方式在高并发下能减少锁竞争。但必须注意volatile关键字的正确使用，否则会出现脑裂问题。类似地，使用线程池时，必须配置合适的corePoolSize和maximumPoolSize，否则会浪费资源或者任务堆积。我见过一些人盲目使用ForkJoinPool，结果因为任务拆分不合理，导致CPU利用率低下。另外，使用线程安全的类如AtomicInteger、AtomicReferenceArray时，要理解它们的CAS机制和ABA问题。这些细节直接关系到程序的稳定性和性能。 围绕Java并发设计模式，我总结出几个关键点。首先是同步机制的选择，比如synchronized、ReentrantLock、StampedLock等。其次，是容器的线程安全性，比如ArrayList和ConcurrentHashMap的区别。还有是线程池的配置，比如如何计算合适的线程数。另外，不可变对象和线程安全的封装方法也是常见手段。我踩过的坑包括在多线程中使用非线程安全的类而未加锁，或者线程池配置过大导致内存溢出。这些经验必须被直接复制，而不是抽象讨论。 如果你正在处理并发任务，必须知道这些模式的使用场景。比如，使用ThreadLocal来隔离线程状态，能有效避免共享数据的冲突。而使用ThreadSafe的类如CopyOnWriteArrayList，适合读多写少的场景。我见过很多项目因为没意识到这一区别，导致性能问题。使用volatile修饰变量可以保证可见性，但不能保证原子性。所以，对复合操作必须用synchronized或者Atomic类来处理。这些细节不是理论，而是实际问题的解决方案。 我见过不少团队因为设计模式使用不当，导致系统在高并发下出现严重问题。比如，没有正确使用并发安全的队列，而是自己实现线程间通信，结果因为条件判断错误导致任务阻塞。或者，没有正确设置线程池拒绝策略，导致任务堆积最终引发OOM。这些问题都源于对并发模式的误解。因此，我建议深入理解每种模式的机制，而不是照搬代码。真正的并发安全需要结合具体业务场景做取舍。 ▌ 技术参考 一 同步容器与并发容器的对比 同步容器如Vector、Hashtable、Stack等，内部通过synchronized修饰关键方法实现线程安全。这些容器适合低并发场景，但高并发下效率极低。比如，Vector的add()方法会锁整个容器，导致多个线程无法并行操作。而并发容器如ConcurrentHashMap、CopyOnWriteArrayList等，采用分段锁或CAS机制，提升并发性能。CoponWriteArrayList在写入时会复制整个数组，因此不适合频繁修改的场景。ConcurrentHashMap则通过分段锁降低锁粒度，支持并发读写。这些容器的使用场景必须与业务需求匹配，否则会带来反效果。 二 双重检查锁定与volatile 双重检查锁定是实现懒汉式单例模式的常见方法。代码中需要对目标对象的引用进行volatile修饰，防止指令重排序。比如： ```java private static volatile Singleton instance; public static Singleton getInstance() { if (instance == null) { synchronized (Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } ``` 这种模式在高并发下能减少锁竞争。但必须保证volatile的正确使用，否则出现脑裂导致多线程获取到重复实例。关键点在于volatile关键字必须放在声明语句中，且必须在if判断后加锁。否则即使代码没错，也可能因为JVM优化导致问题。 三 线程池配置与拒绝策略 线程池的配置直接影响并发性能。例如，使用ThreadPoolExecutor时，合理设置corePoolSize和maximumPoolSize是关键。在单核CPU场景下，corePoolSize应设为1，maximumPoolSize设为当前CPU核心数的2倍。通过设置keepAliveTime和ThreadPoolExecutor.CallerRunsPolicy策略，可以有效控制任务积压。例如： ```java ThreadPoolExecutor executor = new ThreadPoolExecutor( 1, 2, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(100), new ThreadPoolExecutor.CallerRunsPolicy() ); ``` 这种配置在处理突发请求时能起到缓冲作用，但过度配置会浪费内存。使用CallerRunsPolicy让调用线程执行任务，能有效缓解负载压力，但可能降低响应速度。 四 线程安全的类与原子操作 Java提供了一系列线程安全类，如AtomicInteger、AtomicLong、AtomicReference等。这些类基于CAS（Compare and Swap）机制，避免使用锁。例如，AtomicInteger的getAndIncrement()方法在多线程下可以保证原子性，而不需要显式加锁。但CAS存在ABA问题，可以使用AtomicStampedReference或AtomicMarkableReference来解决。例如： ```java AtomicStampedReference ref = new AtomicStampedReference<>(0, 0); ref.compareAndSet(0, 1, 0, 1); ``` 这种模式适用于需要版本号或标记的原子操作，避免误操作。 五 分段锁机制与ConcurrentHashMap ConcurrentHashMap通过分段锁实现线程安全，每个段由一个ReentrantLock保护。这种设计将锁粒度降低到段级别，适合大规模并发写入。例如，在put()操作时，只锁对应的段，不影响其他段。分段锁的实现需要深入理解哈希算法和锁的划分逻辑。需要注意的是，分段锁在Java 8后被取消，改为CAS+synchronized的方式。因此，老版本的ConcurrentHashMap与新版本的实现逻辑不同，必须根据版本调整代码策略。 六 ReentrantLock与Condition ReentrantLock相比synchronized更具灵活性，可以支持多个Condition对象。例如，使用Condition来实现线程等待和唤醒机制： ```java Lock lock = new ReentrantLock(); Condition condition = lock.newCondition(); lock.lock(); try { while (condition) { condition.await(); } } finally { lock.unlock(); } ``` 这种模式适合需要复杂等待条件的场景，比如生产者消费者模型。但ReentrantLock的加锁和解锁必须严格配对，否则可能导致死锁。此外，ReentrantLock的公平锁模式会影响性能，需根据实际场景选择非公平锁。 七 ThreadLocal与线程隔离 ThreadLocal用于隔离线程状态，避免共享变量带来的并发问题。例如，在多线程中使用ThreadLocal来存储数据库连接、用户上下文信息等： ```java ThreadLocal userContext = new ThreadLocal<>(); userContext.set(new UserContext("user1")); ``` 这种模式能有效减少锁竞争，但必须注意内存泄漏问题。在Servlet中，ThreadLocal的使用容易导致线程复用问题，必须配合remove()方法清理资源。否则，多个请求可能会共享同一个UserContext实例，导致数据污染。 八 线程安全对象的封装 将非线程安全对象封装成线程安全的版本是常见做法。例如，使用装饰器模式包装ArrayList为CopyOnWriteArrayList，或者使用Collections.synchronizedList()。这种模式简单有效，但需要明确其适用场景。例如，CopyOnWriteArrayList的写入性能较差，适合读多写少的场景。而Collections.synchronizedList()则需要显式加锁，适合需要精确控制的业务。封装后的对象必须确保所有操作都是线程安全的，否则可能导致数据不一致。 九 Synchronized的局限性 synchronized虽然简单，但在高并发下效率低下。例如，每次调用synchronized方法都会加锁，导致线程阻塞。而使用ReentrantLock可实现更细粒度的锁控制。例如： ```java ReentrantLock lock = new ReentrantLock(); lock.lock(); try { // 业务逻辑 } finally { lock.unlock(); } ``` 此外，synchronized无法中断正在等待的线程，而ReentrantLock支持中断。因此，在需要超时控制的场景下，ReentrantLock更合适。但synchronized的使用更简单，适合代码量小的场景。 十 持久化与并发安全 在数据库操作中，如果多个线程同时写入相同数据，必须保证事务的隔离性。例如，在Spring框架中，可以使用@Transactional注解来确保线程安全。但需要注意，事务默认是基于线程的，因此如果线程池复用线程，可能导致事务污染。解决方案是使用ThreadLocal存储事务信息，或者在框架层面配置事务管理器。例如： ```java @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public void doSomething() { // 业务逻辑 } ``` 这种模式确保每个线程有独立事务，避免数据竞争。但需要注意事务的开销，尤其是频繁的事务提交会影响性能。 十一 并发工具类的使用 Java提供了一系列并发工具类，如CountDownLatch、CyclicBarrier、Semaphore、Exchanger等。例如，使用CountDownLatch来同步多个线程的执行： ```java CountDownLatch latch = new CountDownLatch(3); new Thread(() -> { // 业务逻辑 latch.countDown(); }).start(); latch.await(); ``` 这些工具类能有效简化线程间通信，但使用时必须注意线程的状态和生命周期。例如，CyclicBarrier在达到指定线程数后会释放所有线程，适合分阶段任务。但要避免无限等待，否则会导致线程挂起。 十二 线程池的监控与调优 线程池的性能直接关系到系统的吞吐量。可以使用JMX监控线程池的活跃线程数、队列大小、任务拒绝次数等指标。例如，通过JConsole或VisualVM查看线程池状态。同时，可以调整核心参数如keepAliveTime、queueCapacity、allowCoreThreadTimeOut等。例如： ```java ThreadPoolExecutor executor = new ThreadPoolExecutor( 5, 20, 60, TimeUnit.SECONDS, new LinkedBlockingQueue<>(1000), new ThreadPoolExecutor.CallerRunsPolicy() ); ``` 这种配置适合突发任务，但可能会影响响应时间。需要根据业务特征调整参数，比如CPU密集型任务可能需要更小的队列，而IO密集型任务需要更大的队列。 十三 线程安全的集合操作 在多线程环境中，直接操作集合会导致数据竞争。例如，使用ConcurrentHashMap代替HashMap，或者使用ConcurrentLinkedQueue代替LinkedList。这些容器内部已经处理了线程安全，但必须注意其行为差异。例如，ConcurrentHashMap的put()方法不会阻塞，但get()可能返回旧值。而ConcurrentLinkedQueue的add()方法是异步执行，不保证顺序。因此，必须根据业务需求选择合适的集合类型。 十四 线程安全的算法实现 某些算法需要线程安全，比如计数器、队列调度器等。可以使用Atomic类如AtomicLong、AtomicReferenceArray来实现，或者使用锁机制。例如，实现一个线程安全的计数器： ```java AtomicLong counter = new AtomicLong(0); counter.incrementAndGet(); ``` 这种模式在高并发下性能优于synchronized。但需要注意，Atomic类的CAS操作可能在某些情况下失败，因此需要回退机制。例如，使用retry逻辑处理CAS失败的情况。 十五 CAS机制与ABA问题 CAS是Compare and Swap的缩写，是实现原子操作的核心机制。例如，使用AtomicInteger的compareAndSet()方法实现无锁操作。但CAS存在ABA问题，即值从A变到B再变回A，导致误判。可以使用AtomicStampedReference或AtomicMarkableReference来解决。例如： ```java AtomicStampedReference ref = new AtomicStampedReference<>(0, 0); ref.compareAndSet(0, 1, 0, 1); ``` 这种模式通过引入版本号，避免误判。但会增加额外的开销，适合对性能要求极高的场景。 十六 线程安全的缓存实现 使用线程安全的缓存如ConcurrentHashMap实现策略缓存，或者使用Caffeine等第三方库。例如，在Spring中配置Caffeine缓存： ```java Cache cache = Caffeine.newBuilder() .maximumSize(100) .build(); ``` Caffeine的线程安全机制基于CAS，适合高并发场景。但需要合理设置缓存过期策略，否则可能导致内存泄漏。对于需要频繁更新的缓存，使用CacheWriter可实现异步写入，提升性能。 十七 消息队列与并发控制 在高并发场景下，消息队列可以起到缓冲作用。例如，使用RabbitMQ、Kafka或自定义的BlockingQueue。例如，使用LinkedBlockingQueue： ```java BlockingQueue queue = new LinkedBlockingQueue<>(100); new Thread(() -> { while (true) { Runnable task = queue.poll(); if (task != null) { task.run(); } } }).start(); ``` 这种模式能有效平滑并发请求，但需要注意队列容量和任务处理速度。如果任务处理速度跟不上，队列会不断增长，最终导致内存溢出。 十八 多线程环境下的日志处理 日志在多线程环境中容易出现混乱。例如，使用Logback或Log4j2的异步日志功能，可以避免阻塞主线程。例如，在Logback配置中添加异步Appender： ```xml ``` 这种模式能提升日志性能，但需要合理配置队列大小和日志刷新策略，否则可能导致日志丢失。 十九 本地缓存与并发安全 本地缓存如Guava的Cache或Caffeine，适用于多线程环境。例如，在Guava中配置本地缓存： ```java Cache cache = Caffeine.newBuilder() .maximumSize(100) .build(); ``` 这种模式能避免频繁访问外部资源，但需要注意缓存一致性。例如，使用CacheWriter确保缓存更新与数据源同步。 二十 线程安全的资源配置 在多线程环境中，资源分配必须保证线程安全。例如，使用ThreadLocal存储数据库连接： ```java ThreadLocal connectionHolder = new ThreadLocal<>(); Connection conn = connectionHolder.get(); if (conn == null) { conn = dataSource.getConnection(); connectionHolder.set(conn); } ``` 这种模式能避免资源共享带来的并发问题，但必须注意资源的回收。例如，使用finally块确保连接关闭，或者配合try-with-resources语句。