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 壓縮
? 服務器推送
? 優(yōu)先級請求
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,這個鏈接的當前流數量是否超過了最大并發(fā)流數,然后再匹配地址Address,最后檢測noNewStreams這個值.
這個值,是什么時候被設置為true的呢?
答案是在這個鏈接被移除(remove)的時候.
詳見2個方法:
evictAll()
pruneAndGetAllocationCount(RealConnection connection, long now)
4.回收空閑的鏈接,優(yōu)化鏈接
void put(RealConnection connection) {
assert (Thread.holdsLock(this));
if (!cleanupRunning) {
cleanupRunning = true;
executor.execute(cleanupRunnable);
}
connections.add(connection);
}
每次吧,創(chuàng)建一個鏈接的時候,再將它添加到隊列的時候,都會執(zhí)行一下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,等待之后釋放鎖，繼續(xù)執(zhí)行下一次的清理忌堂。
那么怎么找到閑置的連接是主要解決的問題。
/**
* 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方法,咱們獲得了某個鏈接的并發(fā)流數量,返回到cleanup,
// If the connection is ready to be evicted, we're done.
long idleDurationNs = now - connection.idleAtNanos;
if (idleDurationNs > longestIdleDurationNs) {
longestIdleDurationNs = idleDurationNs;
longestIdleConnection = connection;
}
很簡單的幾行代碼,但是很關鍵,目的是記錄,哪個鏈接是空閑時間最長的,閑了這么長時間,被我逮著了吧,哈哈哈...
繼續(xù)向下走,找組織
if (longestIdleDurationNs >= this.keepAliveDurationNs ||
idleConnectionCount > this.maxIdleConnections)
這就是溢出空閑鏈接的原因,滿足2個條件中的任意一個,你就被開除了,要么你這個RealConnection已經閑得發(fā)慌,要么當前閑的人太多了,你就悲劇了,拜拜吧...
最關鍵的怎么知道下一次掃蕩的時間呢?
'你問我,我問誰?'
'好吧,看代碼!'
跟著組織繼續(xù)走
第一個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;
發(fā)現有人頂風作案,會不會有同伙,那好,立即再次掃蕩,所以時間緊迫,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最核心的思想,連接復用就梳理完了.
