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


最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容