OkHttp3源码详解之 okhttp连接池复用机制（一），移动智能终端开发报告
作者：互联网
/** Returns a recycled connection to {@code address}, or null if no such connection exists. */
RealConnection get(Address address, StreamAllocation streamAllocation) {
assert (Thread.holdsLock(this));
for (RealConnection connection : connections) {
if (connection.allocations.size() < connection.allocationLimit
&& address.equals(connection.route().address)
&& !connection.noNewStreams) {
streamAllocation.acquire(connection);
return connection;
}
}
return null;
}
遍历connections缓存列表，当某个连接计数的次数小于限制的大小以及request的地址和缓存列表中此连接的地址完全匹配。则直接复用缓存列表中的connection作为request的连接。
streamAllocation.allocations是个对象计数器，其本质是一个 List<Reference> 存放在RealConnection连接对象中用于记录Connection的活跃情况。
连接池中Connection的缓存比较简单，就是利用一个双端列表，配合CRD等操作。那么connection在timeout时间类是如果失效的呢，并且如果做到有效的对连接进行清除操作以确保性能和内存空间的充足。
2.2 连接池的清理和回收
在看ConnectionPool的成员变量的时候我们了解到一个Executor的线程池是用来清理闲置的连接的。注释中是这么解释的：
Background threads are used to cleanup expired connections
我们在put新连接到队列的时候会先执行清理闲置连接的线程。调用的正是 executor.execute(cleanupRunnable); 方法。观察cleanupRunnable
private final Runnable cleanupRunnable = new Runnable() {
@Override public void run() {
while (true) {
long waitNanos = cleanup(System.nanoTime());
if (waitNanos == -1) return;
if (waitNanos > 0) {
long waitMillis = waitNanos / 1000000L;
waitNanos -= (waitMillis * 1000000L);
synchronized (ConnectionPool.this) {
try {
ConnectionPool.this.wait(waitMillis, (int) waitNanos);
} catch (InterruptedException ignored) {
}
}
}
}
}
};
线程中不停调用Cleanup 清理的动作并立即返回下次清理的间隔时间。继而进入wait 等待之后释放锁，继续执行下一次的清理。所以可能理解成他是个监测时间并释放连接的后台线程。
了解cleanup动作的过程。这里就是如何清理所谓闲置连接的和行了。怎么找到闲置的连接是主要解决的问题。
long cleanup(long now) {
int inUseConnectionCount = 0;
int idleConnectionCount = 0;
RealConnection longestIdleConnection = null;
long longestIdleDurationNs = Long.MIN_VALUE;
// Find either a connection to evict, or the time that the next eviction is due.
synchronized (this) {
for (Iterator i = connections.iterator(); i.hasNext(); ) {
RealConnection connection = i.next();
// If the connection is in use, keep searching.
if (pruneAndGetAllocationCount(connection, now) > 0) {
inUseConnectionCount++;
continue;
}
idleConnectionCount++;
// If the connection is ready to be evicted, we’re done.
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;
}
}
if (longestIdleDurationNs >= this.keepAliveDurationNs
|| idleConnectionCount > this.maxIdleConnections) {
// We’ve found a connection to evict. Remove it from the list, then close it below (outside
// of the synchronized block).
connections.remove(longestIdleConnection);
} else if (idleConnectionCount > 0) {
// A connection will be ready to evict soon.
return keepAliveDurationNs - longestIdleDurationNs;
} else if (inUseConnectionCount > 0) {
// All connections are in use. It’ll be at least the keep alive duration 'til we run again.
return keepAliveDurationNs;
} else {
// No connections, idle or in use.
cleanupRunning = false;
return -1;
}
}
closeQuietly(longestIdleConnection.socket());
// Cleanup again immediately.
return 0;
}
在遍历缓存列表的过程中，使用连接数目inUseConnectionCount 和闲置连接数目idleConnectionCount 的计数累加值都是通过pruneAndGetAllocationCount() 是否大于0来控制的。那么很显然pruneAndGetAllocationCount() 方法就是用来识别对应连接是否闲置的。>0则不闲置。否则就是闲置的连接。
进去观察
private int pruneAndGetAllocationCount(RealConnection connection, long now) {
List<Reference> references = connection.allocations;
for (int i = 0; i < references.size(); ) {
Reference reference = references.get(i);
if (reference.get() != null) {
i++;
continue;
}
// We’ve discovered a leaked allocation. This is an application bug.
Platform.get().log(WARN, "A connection to " + connection.route().address().url()
- " was leaked. Did you forget to close a response body?", null);
references.remove(i);
connection.noNewStreams = true;
// If this was the last allocation, the connection is eligible for immediate eviction.
if (references.isEmpty()) {
connection.idleAtNanos = now - keepAliveDurationNs;
return 0;
}
}
return references.size();
}
}
好了，原先存放在RealConnection 中的allocations 派上用场了。遍历StreamAllocation 弱引用链表，移除为空的引用，遍历结束后返回链表中弱引用的数量。所以可以看出List<Reference> 就是一个记录connection活跃情况的 >0表示活跃 =0 表示空闲。StreamAllocation 在列表中的数量就是就是物理socket被引用的次数
解释：StreamAllocation被高层反复执行aquire与release。这两个函数在执行过程中其实是在一直在改变Connection中的 List<WeakReference>大小。
搞定了查找闲置的connection操作，我们回到cleanup 的操作。计算了inUseConnectionCount和idleConnectionCount 之后程序又根据闲置时间对connection进行了一个选择排序，选择排序的核心是：
// If the connection is ready to be evicted, we’re done.
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;
}
}
…
// If the connection is ready to be evicted, we’re done.
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;[外链图片转存中…(img-B2TjHLAc-1643360161897)]
}
}
…
标签：return,longestIdleDurationNs,long,连接,connection,源码,OkHttp3,idleDurationNs,连接池 来源： https://blog.csdn.net/m0_66264630/article/details/122733791