OkHttp链接复用

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 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.
   *
   * 

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 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> 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.
      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> 就是一个记录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 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最核心的思想,连接复用就梳理完了.


你可能感兴趣的:(OkHttp链接复用)