在Java高并发场景下，资源池是复用昂贵资源（如数据库连接、网络连接、线程等）的常用设计，其核心目标是高效分配资源的同时保证线程安全，避免资源重复分配、泄漏或状态混乱。合理的并发控制是资源池稳定运行的基石。
核心设计思路
高并发安全的资源池设计需要解决三个核心问题：资源的统一存储管理、获取资源时的线程安全控制、资源回收时的状态重置与归还。通常我们会维护一个空闲资源集合，当线程请求资源时从集合中取出，使用完毕后归还到集合中，整个过程需要保证集合操作的原子性和可见性。
基础版：使用synchronized实现
最基础的并发控制方式是使用synchronized关键字对资源池的核心操作加锁，保证同一时间只有一个线程能修改资源池状态。这种方式实现简单，但锁粒度较粗，高并发下性能较差。
import java.util.ArrayList;
import java.util.List;
public class SimpleResourcePool<T> {
// 空闲资源集合
private final List<T> idleResources;
// 资源池最大容量
private final int maxSize;
// 资源工厂，用于创建新资源
private final ResourceFactory<T> factory;
public SimpleResourcePool(int maxSize, ResourceFactory<T> factory) {
this.maxSize = maxSize;
this.factory = factory;
this.idleResources = new ArrayList<>(maxSize);
// 初始化部分资源
for (int i = 0; i < Math.min(maxSize, 10); i++) {
idleResources.add(factory.createResource());
}
}
// 获取资源
public synchronized T getResource() throws Exception {
// 空闲集合有资源，直接返回
if (!idleResources.isEmpty()) {
return idleResources.remove(idleResources.size() - 1);
}
// 没有空闲资源且未达到最大容量，创建新资源
if (idleResources.size() < maxSize) {
return factory.createResource();
}
// 达到最大容量，等待其他线程归还资源
wait();
return getResource();
}
// 归还资源
public synchronized void returnResource(T resource) {
// 重置资源状态
resetResource(resource);
idleResources.add(resource);
// 唤醒等待获取资源的线程
notifyAll();
}
// 重置资源状态，避免脏数据
private void resetResource(T resource) {
// 具体资源重置逻辑，根据资源类型实现
}
// 资源工厂接口
public interface ResourceFactory<T> {
T createResource();
}
}
优化版：使用ReentrantLock+Condition
相比synchronized，ReentrantLock支持更灵活的条件队列，我们可以为资源池创建两个条件：一个用于等待空闲资源，一个用于等待资源池有空位，减少不必要的线程唤醒，提升性能。
import java.util.ArrayDeque;
import java.util.Deque;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.ReentrantLock;
public class LockResourcePool<T> {
private final Deque<T> idleResources;
private final int maxSize;
private final ResourceFactory<T> factory;
private final ReentrantLock lock;
// 等待空闲资源的条件
private final Condition notEmpty;
// 等待资源池有空位的条件
private final Condition notFull;
public LockResourcePool(int maxSize, ResourceFactory<T> factory) {
this.maxSize = maxSize;
this.factory = factory;
this.idleResources = new ArrayDeque<>(maxSize);
this.lock = new ReentrantLock();
this.notEmpty = lock.newCondition();
this.notFull = lock.newCondition();
// 初始化资源
for (int i = 0; i < Math.min(maxSize, 10); i++) {
idleResources.add(factory.createResource());
}
}
public T getResource() throws InterruptedException {
lock.lock();
try {
// 空闲资源为空，等待
while (idleResources.isEmpty()) {
notEmpty.await();
}
return idleResources.pollLast();
} finally {
lock.unlock();
}
}
public void returnResource(T resource) {
lock.lock();
try {
resetResource(resource);
// 如果当前资源池已满，等待空位
while (idleResources.size() >= maxSize) {
notFull.await();
}
idleResources.add(resource);
// 唤醒等待获取资源的线程
notEmpty.signal();
} finally {
lock.unlock();
}
}
private void resetResource(T resource) {
// 资源重置逻辑
}
public interface ResourceFactory<T> {
T createResource();
}
}
高性能版：使用并发容器+信号量
如果资源创建成本较低，我们可以使用ConcurrentLinkedQueue作为空闲资源容器，配合Semaphore控制资源的总并发访问量，这种方式锁竞争更少，高并发下性能更优。
import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.Semaphore;
public class SemaphoreResourcePool<T> {
private final ConcurrentLinkedQueue<T> idleResources;
private final Semaphore semaphore;
private final ResourceFactory<T> factory;
private final int maxSize;
public SemaphoreResourcePool(int maxSize, ResourceFactory<T> factory) {
this.maxSize = maxSize;
this.factory = factory;
this.idleResources = new ConcurrentLinkedQueue<>();
this.semaphore = new Semaphore(maxSize);
// 初始化资源
for (int i = 0; i < Math.min(maxSize, 10); i++) {
idleResources.add(factory.createResource());
}
}
public T getResource() throws InterruptedException {
// 获取信号量许可，没有许可则阻塞
semaphore.acquire();
T resource = idleResources.poll();
if (resource != null) {
return resource;
}
// 没有空闲资源，创建新资源（需要控制总数量不超过maxSize）
return factory.createResource();
}
public void returnResource(T resource) {
resetResource(resource);
idleResources.add(resource);
// 释放信号量许可
semaphore.release();
}
private void resetResource(T resource) {
// 资源重置逻辑
}
public interface ResourceFactory<T> {
T createResource();
}
}
不同方案对比
| 实现方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| synchronized版本 | 实现简单，无额外依赖 | 锁粒度粗，性能较差 | 低并发场景，资源池规模小 |
| ReentrantLock版本 | 锁控制灵活，可减少无效唤醒 | 代码复杂度稍高 | 中高并发场景，需要精细控制等待逻辑 |
| 信号量+并发容器版本 | 性能最优，锁竞争少 | 资源创建无上限控制（需额外逻辑） | 高并发场景，资源创建成本较低 |
注意事项
- 资源归还时必须重置资源状态，避免下一个使用者拿到脏数据
- 需要做好异常处理，防止资源使用过程中抛出异常导致资源无法归还
- 可以根据业务需求添加资源池监控，统计资源使用率、等待时长等指标
- 资源空闲过久可以设置过期回收机制，避免资源长期占用内存
资源池的并发控制没有绝对最优的方案，需要根据实际业务的并发量、资源特性选择合适的实现方式，在安全性和性能之间找到平衡。