Java并发编程中，惊群效应是指多个线程同时等待某个条件触发，当条件满足时所有等待线程被一次性唤醒，随后共同竞争同一资源，最终仅少数线程能成功获取资源，其余线程再次陷入等待的现象，这会额外消耗CPU资源，引发程序性能抖动。
惊群效应的产生原理
在Java的并发工具中，很多等待唤醒机制的设计如果没有做针对性优化，就容易出现惊群效应。比如使用Object.wait()和Object.notifyAll()的组合时，notifyAll()会唤醒所有等待在该对象监视器上的线程，这些线程被唤醒后会同时去竞争对象锁，而同一时间只有持有锁的线程能继续执行，其余线程竞争失败后只能再次阻塞。
类似的场景也出现在早期的ReentrantLock搭配Condition使用signalAll()方法时，同样会唤醒所有等待在该Condition上的线程，引发批量竞争。
惊群效应带来的实际影响
惊群效应的核心问题是无效的资源竞争，具体影响可以分为以下几点：
- CPU使用率飙升：大量线程被唤醒后同时竞争锁，会频繁触发上下文切换，占用大量CPU资源。
- 响应延迟增加：竞争失败的线程需要重新进入等待队列，延长了任务的处理周期。
- 系统吞吐量下降：无效的竞争消耗了系统资源，实际能处理的业务请求数量会减少。
常见的惊群效应场景示例
下面用一个简单的示例模拟惊群效应的产生过程，代码中创建10个线程等待同一个对象锁，当主线程调用notifyAll()后，所有线程被唤醒竞争锁：
public class ThunderingHerdDemo {
private static final Object lock = new Object();
private static boolean condition = false;
public static void main(String[] args) throws InterruptedException {
// 创建10个等待线程
for (int i = 0; i < 10; i++) {
int threadId = i;
new Thread(() -> {
synchronized (lock) {
// 等待条件满足
while (!condition) {
try {
System.out.println("线程" + threadId + "进入等待状态");
lock.wait();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
// 竞争到锁后执行逻辑
System.out.println("线程" + threadId + "获取到锁，执行任务");
}
}).start();
}
// 休眠1秒，确保所有线程都进入等待状态
Thread.sleep(1000);
synchronized (lock) {
condition = true;
// 唤醒所有等待线程，触发惊群效应
lock.notifyAll();
}
}
}
运行上述代码可以看到，所有线程被唤醒后会依次竞争锁，每次只有一个线程能拿到锁执行任务，其余线程竞争失败后会重新等待，这就是典型的惊群效应表现。
惊群效应的缓解方案
1. 使用notify()替代notifyAll()
如果场景中只需要唤醒一个等待线程，优先使用notify()方法，它只会随机唤醒一个等待在该对象上的线程，避免大量线程同时被唤醒竞争。但需要注意notify()可能导致某些线程永远无法被唤醒，适合所有等待线程任务逻辑一致的场景。
2. 使用ReentrantLock的Condition精准唤醒
如果需要根据不同的条件唤醒不同的线程，可以使用ReentrantLock创建多个Condition对象，每个条件对应一个Condition，唤醒时只调用对应Condition的signal()方法，避免唤醒无关线程。
示例代码如下：
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
public class ConditionSignalDemo {
private static final ReentrantLock lock = new ReentrantLock();
// 创建两个不同条件的Condition
private static final Condition conditionA = lock.newCondition();
private static final Condition conditionB = lock.newCondition();
private static boolean flagA = false;
private static boolean flagB = false;
public static void main(String[] args) throws InterruptedException {
// 等待条件A的线程
new Thread(() -> {
lock.lock();
try {
while (!flagA) {
conditionA.await();
}
System.out.println("条件A的线程执行任务");
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
lock.unlock();
}
}).start();
// 等待条件B的线程
new Thread(() -> {
lock.lock();
try {
while (!flagB) {
conditionB.await();
}
System.out.println("条件B的线程执行任务");
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
} finally {
lock.unlock();
}
}).start();
Thread.sleep(1000);
lock.lock();
try {
flagA = true;
// 只唤醒等待条件A的线程，不会影响等待条件B的线程
conditionA.signal();
} finally {
lock.unlock();
}
}
}
3. 使用并发容器或原子类减少锁竞争
如果场景是多个线程竞争操作同一份数据，可以优先使用无锁的并发容器（如ConcurrentHashMap、CopyOnWriteArrayList）或者原子类（如AtomicInteger），从根源上减少锁的使用，避免惊群效应。
4. 使用线程池配合任务队列削峰
如果是大量线程同时等待处理任务，可以使用有界任务队列的线程池，控制同时处理任务的线程数量，避免所有线程同时被唤醒竞争资源。比如使用ThreadPoolExecutor时设置合理的核心线程数和队列长度，让任务排队处理，减少并发竞争。
总结
惊群效应本质是并发场景中唤醒机制的粒度太粗，导致不必要的批量线程竞争。实际开发中需要根据场景选择合适的唤醒策略，优先使用精准唤醒的方式，或者减少锁的使用，从而规避惊群效应带来的性能问题。在高并发场景下，提前评估等待唤醒机制的影响，能有效提升系统的稳定性和运行效率。