OkHttp3源碼詳解(五) okhttp連接池復(fù)用機(jī)制
1、概述
提高網(wǎng)絡(luò)性能優(yōu)化,很重要的一點(diǎn)就是降低延遲和提升響應(yīng)速度。
通常我們?cè)跒g覽器中發(fā)起請(qǐng)求的時(shí)候header部分往往是這樣的

keep-alive 就是瀏覽器和服務(wù)端之間保持長(zhǎng)連接,這個(gè)連接是可以復(fù)用的。在HTTP1.1中是默認(rèn)開啟的。
連接的復(fù)用為什么會(huì)提高性能呢?
通常我們?cè)诎l(fā)起http請(qǐng)求的時(shí)候首先要完成tcp的三次握手,然后傳輸數(shù)據(jù),最后再釋放連接。三次握手的過程可以參考這里 TCP三次握手詳解及釋放連接過程
一次響應(yīng)的過程

在高并發(fā)的請(qǐng)求連接情況下或者同個(gè)客戶端多次頻繁的請(qǐng)求操作,無限制的創(chuàng)建會(huì)導(dǎo)致性能低下。
如果使用keep-alive

在timeout空閑時(shí)間內(nèi),連接不會(huì)關(guān)閉,相同重復(fù)的request將復(fù)用原先的connection,減少握手的次數(shù),大幅提高效率。
并非keep-alive的timeout設(shè)置時(shí)間越長(zhǎng),就越能提升性能。長(zhǎng)久不關(guān)閉會(huì)造成過多的僵尸連接和泄露連接出現(xiàn)。
那么okttp在客戶端是如果類似于客戶端做到的keep-alive的機(jī)制。
2、連接池的使用
連接池的類位于okhttp3.ConnectionPool。我們的主旨是了解到如何在timeout時(shí)間內(nèi)復(fù)用connection,并且有效的對(duì)其進(jìn)行回收清理操作。
其成員變量代碼片
/** * Background threads are used to cleanup expired connections. There will be at most a single * thread running per connection pool. The thread pool executor permits the pool itself to be * garbage collected. */ private static final Executor executor = new ThreadPoolExecutor(0 /* corePoolSize */, Integer.MAX_VALUE /* maximumPoolSize */, 60L /* keepAliveTime */, TimeUnit.SECONDS, new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp ConnectionPool", true)); /** The maximum number of idle connections for each address. */ private final int maxIdleConnections; private final Deque<RealConnection> connections = new ArrayDeque<>(); final RouteDatabase routeDatabase = new RouteDatabase(); boolean cleanupRunning;
- excutor : 線程池,用來檢測(cè)閑置socket并對(duì)其進(jìn)行清理。
- connections : connection緩存池。Deque是一個(gè)雙端列表,支持在頭尾插入元素,這里用作LIFO(后進(jìn)先出)堆棧,多用于緩存數(shù)據(jù)。
- routeDatabase :用來記錄連接失敗router
2.1 緩存操作
ConnectionPool提供對(duì)Deque<RealConnection>進(jìn)行操作的方法分別為put、get、connectionBecameIdle、evictAll幾個(gè)操作。分別對(duì)應(yīng)放入連接、獲取連接、移除連接、移除所有連接操作。
put操作
void put(RealConnection connection) { assert (Thread.holdsLock(this)); if (!cleanupRunning) { cleanupRunning = true; executor.execute(cleanupRunnable); } connections.add(connection); }
可以看到在新的connection 放進(jìn)列表之前執(zhí)行清理閑置連接的線程。
既然是復(fù)用,那么看下他獲取連接的方式。
/** 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緩存列表,當(dāng)某個(gè)連接計(jì)數(shù)的次數(shù)小于限制的大小以及request的地址和緩存列表中此連接的地址完全匹配。則直接復(fù)用緩存列表中的connection作為request的連接。
streamAllocation.allocations是個(gè)對(duì)象計(jì)數(shù)器,其本質(zhì)是一個(gè)
List<Reference<StreamAllocation>>存放在RealConnection連接對(duì)象中用于記錄Connection的活躍情況。
連接池中Connection的緩存比較簡(jiǎn)單,就是利用一個(gè)雙端列表,配合CRD等操作。那么connection在timeout時(shí)間類是如果失效的呢,并且如果做到有效的對(duì)連接進(jìn)行清除操作以確保性能和內(nèi)存空間的充足。
2.2 連接池的清理和回收
在看ConnectionPool的成員變量的時(shí)候我們了解到一個(gè)Executor的線程池是用來清理閑置的連接的。注釋中是這么解釋的:
Background threads are used to cleanup expired connections
我們?cè)趐ut新連接到隊(duì)列的時(shí)候會(huì)先執(zhí)行清理閑置連接的線程。調(diào)用的正是 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) { } } } } } };
線程中不停調(diào)用Cleanup 清理的動(dòng)作并立即返回下次清理的間隔時(shí)間。繼而進(jìn)入wait 等待之后釋放鎖,繼續(xù)執(zhí)行下一次的清理。所以可能理解成他是個(gè)監(jiān)測(cè)時(shí)間并釋放連接的后臺(tái)線程。
了解cleanup動(dòng)作的過程。這里就是如何清理所謂閑置連接的和行了。怎么找到閑置的連接是主要解決的問題。
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; }
在遍歷緩存列表的過程中,使用連接數(shù)目inUseConnectionCount 和閑置連接數(shù)目idleConnectionCount 的計(jì)數(shù)累加值都是通過pruneAndGetAllocationCount() 是否大于0來控制的。那么很顯然pruneAndGetAllocationCount() 方法就是用來識(shí)別對(duì)應(yīng)連接是否閑置的。>0則不閑置。否則就是閑置的連接。
進(jìn)去觀察
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. 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 派上用場(chǎng)了。遍歷StreamAllocation 弱引用鏈表,移除為空的引用,遍歷結(jié)束后返回鏈表中弱引用的數(shù)量。所以可以看出List<Reference<StreamAllocation>> 就是一個(gè)記錄connection活躍情況的 >0表示活躍 =0 表示空閑。StreamAllocation 在列表中的數(shù)量就是就是物理socket被引用的次數(shù)
解釋:StreamAllocation被高層反復(fù)執(zhí)行aquire與release。這兩個(gè)函數(shù)在執(zhí)行過程中其實(shí)是在一直在改變Connection中的 List<WeakReference<StreamAllocation>>大小。
搞定了查找閑置的connection操作,我們回到cleanup 的操作。計(jì)算了inUseConnectionCount和idleConnectionCount 之后程序又根據(jù)閑置時(shí)間對(duì)connection進(jìn)行了一個(gè)選擇排序,選擇排序的核心是:
// If the connection is ready to be evicted, we're done. long idleDurationNs = now - connection.idleAtNanos; if (idleDurationNs > longestIdleDurationNs) { longestIdleDurationNs = idleDurationNs; longestIdleConnection = connection; } } ....
通過對(duì)比最大閑置時(shí)間選擇排序可以方便的查找出閑置時(shí)間最長(zhǎng)的一個(gè)connection。如此一來我們就可以移除這個(gè)沒用的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); }
總結(jié):清理閑置連接的核心主要是引用計(jì)數(shù)器
List<Reference<StreamAllocation>>和選擇排序的算法以及excutor的清理線程池。
部分參考:http://www.jianshu.com/p/92a61357164b
posted on 2018-08-02 16:43 安卓筆記俠 閱讀(7293) 評(píng)論(0) 收藏 舉報(bào)
浙公網(wǎng)安備 33010602011771號(hào)