经典的等待/通知机制
消费者
获取对象的?
如果条件不满足,wait,被通知后仍要检查条件
条件满足,执行对应的逻辑
synchronized(对象) {
while(条件不满足) {
对象.wait();
}
执行task
}
生产者
获取对象的?
改变条件
通知所有等待该对象的线程
synchronized(对象) {
改变条件
对象.notifyall();
}
超时等待/通知机制
但是实际使用中,会加入超时,保证消费者不会一直等待下去,阻塞该线程做其他的事情;
循环条件中加入判断剩余时间remaining这个条件:
public synchronized Object get(long mills) throws InterruptedException {
Obejct condition = null;
if (mills <= 0) {
while (condition == null) {
wait();
}
} else {
long future = System.currentTimeMillis() + mills;
long remaining = mills;
// 当超时大于0,并且条件不满足要求
while (condition == null && remaining > 0) {
// ⚠️等待remaining时间,而不是mills,防止额外等待mills时间
wait(remaining);
remaining = future - System.currentTimeMillis();
}
}
return condition;
}
简单的数据库连接池
连接池
public class ConnectionPool {
private LinkedList<Connection> pool = new LinkedList<>();
public ConnectionPool(int initialSize) {
for (int i = 0; i < initialSize; i++) {
pool.add(ConnectionDriver.createConnection());
}
}
public void releaseConnection(Connection connection) {
if (connection != null) {
synchronized (pool) {
// TODO 如何保证是原来的connection?,不会打满了?
pool.addLast(connection);
pool.notifyAll();
}
}
}
public Connection fetchConnection(long mills) throws InterruptedException {
synchronized (pool) {
if (mills <= 0) {
while (pool.isEmpty()) {
pool.wait();
}
} else {
long future = System.currentTimeMillis() + mills;
// long remain = future - System.currentTimeMillis();
long remaining = mills;
while (pool.isEmpty() && remaining > 0) {
pool.wait(remaining);
remaining = future - System.currentTimeMillis();
}
}
return pool.isEmpty() ? null : pool.removeFirst();
}
}
}
连接驱动
public class ConnectionDriver {
static class ConnectionHandler implements InvocationHandler {
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
if (method.getName().equals("commit")) {
TimeUnit.MILLISECONDS.sleep(100);
}
return null;
}
}
// 创建一个Connection的代理,在commit时休眠100毫秒
public static final Connection createConnection() {
return (Connection) Proxy.newProxyInstance(ConnectionDriver.class.getClassLoader(),
new Class<?>[]{Connection.class}, new ConnectionHandler());
}
测试代码
public class ConnectionPoolTest {
static ConnectionPool pool = new ConnectionPool(10);
static CountDownLatch start = new CountDownLatch(1);
static CountDownLatch end;
public static void main(String[] args) throws Exception {
int threadCount = 10;
end = new CountDownLatch(threadCount);
int count = 10;
AtomicInteger got = new AtomicInteger();
AtomicInteger notGot = new AtomicInteger();
for (int i = 0; i < threadCount; i++) {
Thread thread = new Thread(new ConnectionRunner(count, got, notGot), "ConnectionRunnerThread " + i);
thread.start();
}
Profiler.begin();
start.countDown();
end.await();
System.out.println("total invoke: " + (threadCount * count));
System.out.println("got connection: " + got);
System.out.println("not got connection " + notGot);
System.out.println("total time: " + Profiler.end());
}
static class ConnectionRunner implements Runnable {
int count;
AtomicInteger got;
AtomicInteger notGot;
public ConnectionRunner(int count, AtomicInteger got, AtomicInteger notGot) {
this.count = count;
this.got = got;
this.notGot = notGot;
}
/**
* When an object implementing interface <code>Runnable</code> is used
* to create a thread, starting the thread causes the object's
* <code>run</code> method to be called in that separately executing
* thread.
* <p>
* The general contract of the method <code>run</code> is that it may
* take any action whatsoever.
*
* @see Thread#run()
*/
@Override
public void run() {
try {
start.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
for (int i = 0; i < count; i++) {
Connection connection;
try {
connection = pool.fetchConnection(1000);
if (connection != null) {
try {
connection.createStatement();
connection.commit();
} catch (SQLException e) {
e.printStackTrace();
} finally {
pool.releaseConnection(connection);
got.incrementAndGet();
}
} else {
// System.out.println(Thread.currentThread() + " : " + i + " failed");
notGot.incrementAndGet();
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
end.countDown();
}
}
}
如果连接池的连接数量固定,测试发现随着客户端线程增多,任务失败比例会增大;这个很容易理解,每次都是M个线程,去争抢N个资源;M大于N,就会出现无法抢到资源的线程,如果多次无法抢到,达到超时时间,自然就会失败。
实际使用中,控制客户端线程数量和资源数量的比例。当然任务时间和超时时间都是需要仔细考量的因素。
总结
-
客户端并发数量m, 资源池的资源数量n,单个任务时间taskTime,超时时间timeout – 成功率
-
如果完全公平锁,可以保证时间T内,做完T/taskTime任务,理论可以100%成功率处理并发数为 timeout/taskTime * (n)的客户端