OkHttp是一个高效的HTTP库
Ø 支持 SPDY ,共享同一个Socket来处理同一个服务器的所有请求;
Ø 如果SPDY不可用,则通过连接池来减少请求延时;
Ø 无缝的支持GZIP来减少数据流量;
Ø 缓存响应数据来减少重复的网络请求。
源码地址:
https://github.com/square/okhttp
核心类ConnectionPool.java
** * Manages reuse of HTTP and HTTP/2 connections for reduced
network latency. HTTP requests that * share the same {@link Address}
may share a {@link Connection}. This class implements the policy * of
which connections to keep open for future use. */
关键支持HTTP和HTTP/2协议
HTTP 2.0 相比 1.1 的更新大部分集中于:
Ø 多路复用
Ø HEAD 压缩
Ø 服务器推送
Ø 优先级请求
1.默认构造方法,无参和有参
/**
* Create a new connection pool with tuning parameters appropriate for a single-user application.
* The tuning parameters in this pool are subject to change in future OkHttp releases. Currently
* this pool holds up to 5 idle connections which will be evicted after 5 minutes of inactivity.
*/
public ConnectionPool() {
this(5, 5, TimeUnit.MINUTES);
}
public ConnectionPool(int maxIdleConnections, long keepAliveDuration, TimeUnit timeUnit) {
this.maxIdleConnections = maxIdleConnections;
this.keepAliveDurationNs = timeUnit.toNanos(keepAliveDuration);
// Put a floor on the keep alive duration, otherwise cleanup will spin loop.
if (keepAliveDuration <= 0) {
throw new IllegalArgumentException("keepAliveDuration <= 0: " + keepAliveDuration);
}
}
现在的okhttp,默认是保持了5个空闲链接,空闲链接超过5分钟将被移除.
private final Deque<RealConnection> connections = new ArrayDeque<>();
2.OkHttp采用了一个双端队列去缓存所有链接对象.
3.如果一个请求来了,看看是怎么返回一个可用链接的
/** 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;
}
可以看到遍历队列,先判断connection.allocations.size() < connection.allocationLimit
,这个链接的当前流数量是否超过了最大并发流数,然后再匹配地址Address,最后检测noNewStreams这个值.
这个值,是什么时候被设置为true的呢?
答案是在这个链接被移除(remove)的时候.
详见2个方法:
evictAll()
pruneAndGetAllocationCount(RealConnection connection, long now)
4.回收空闲的链接,优化链接
void put(RealConnection connection) {
assert (Thread.holdsLock(this));
if (!cleanupRunning) {
cleanupRunning = true;
executor.execute(cleanupRunnable);
}
connections.add(connection);
}
每次吧,创建一个链接的时候,再将它添加到队列的时候,都会执行一下clean操作
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,等待之后释放锁,继续执行下一次的清理。
那么怎么找到闲置的连接是主要解决的问题。
/**
* Performs maintenance on this pool, evicting the connection that has been idle the longest if
* either it has exceeded the keep alive limit or the idle connections limit.
*
* <p>Returns the duration in nanos to sleep until the next scheduled call to this method. Returns
* -1 if no further cleanups are required.
*/
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<RealConnection> 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;
}
在遍历缓存列表的过程中,这里涉及2个数目:连接数目inUseConnectionCount
和空闲连接数目idleConnectionCount
, 它们的值跟随着pruneAndGetAllocationCount()
返回值而变化。那么很显然pruneAndGetAllocationCount()
方法就是用来识别对应连接是否闲置的。>0则不闲置。否则就是闲置的连接。
private int pruneAndGetAllocationCount(RealConnection connection, long now) {
List<Reference<StreamAllocation>> references = connection.allocations;
for (int i = 0; i < references.size(); ) {
Reference<StreamAllocation> reference = references.get(i);
if (reference.get() != null) {
i++;
continue;
}
// We've discovered a leaked allocation. This is an application bug.
StreamAllocation.StreamAllocationReference streamAllocRef =
(StreamAllocation.StreamAllocationReference) reference;
String message = "A connection to " + connection.route().address().url()
+ " was leaked. Did you forget to close a response body?";
Platform.get().logCloseableLeak(message, streamAllocRef.callStackTrace);
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<StreamAllocation>>
就是一个记录connection活跃情况的 >0表示活跃, =0 表示空闲。StreamAllocation 在列表中的数量就是就是物理socket被引用的次数
StreamAllocation.java
public void acquire(RealConnection connection) {
assert (Thread.holdsLock(connectionPool));
connection.allocations.add(new StreamAllocationReference(this, callStackTrace));
}
/** Remove this allocation from the connection's list of allocations. */
private void release(RealConnection connection) {
for (int i = 0, size = connection.allocations.size(); i < size; i++) {
Reference<StreamAllocation> reference = connection.allocations.get(i);
if (reference.get() == this) {
connection.allocations.remove(i);
return;
}
}
throw new IllegalStateException();
}
ok,通过pruneAndGetAllocationCount
方法,咱们获得了某个链接的并发流数量,返回到cleanup
,
// 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)
这就是溢出空闲链接的原因,满足2个条件中的任意一个,你就被开除了,要么你这个RealConnection已经闲得发慌,要么当前闲的人太多了,你就悲剧了,拜拜吧...
最关键的怎么知道下一次扫荡的时间呢?
'你问我,我问谁?'
'好吧,看代码!'
跟着组织继续走
第一个case
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);
}
return 0;
发现有人顶风作案,会不会有同伙,那好,立即再次扫荡,所以时间紧迫,return后立即再次清理.
第二个case
if (idleConnectionCount > 0) {
// A connection will be ready to evict soon.
return keepAliveDurationNs - longestIdleDurationNs;
}
哈哈,你敢不老实,你已经透支了longestIdleDurationNs这么长时间,如果再过 keepAliveDurationNs - longestIdleDurationNs
这么长时间,你还在透支,那么对不起,你被标记了,拉黑.
第三个case
if (inUseConnectionCount > 0) {
// All connections are in use. It'll be at least the keep alive duration 'til we run again.
return keepAliveDurationNs;
}
大家都在干活,貌似都挺乖,好吧,正常运转,下次过keepAliveDurationNs
(默认5分钟)正常时间,再看看.
第四个case
也就是前3个情况都不成立.inUseConnectionCount == 0
// No connections, idle or in use.
cleanupRunning = false;
return -1;
哈哈,没人干活,放假吧.
cleanupRunnable的run方法
while (true) {
long waitNanos = cleanup(System.nanoTime());
if (waitNanos == -1) return;
...
}
自此,okhttp最核心的思想,连接复用就梳理完了.