Okio源码分析与性能优化思想

Okio的优势

private static final ByteString PNG_HEADER = ByteString.decodeHex("89504e470d0a1a0a");

public void decodePng(InputStream in) throws IOException {
  BufferedSource pngSource = Okio.buffer(Okio.source(in));

  ByteString header = pngSource.readByteString(PNG_HEADER.size());
  if (!header.equals(PNG_HEADER)) {
    throw new IOException("Not a PNG.");
  }
}

这个是Okio官方提供了一个png图片的解码的例子，我们知道一般判断一个文件的格式就是依靠前面的校验码，比如class文件中前面的16进制代码就是以 cafebabe 开头，同样的常规的png，jpg，gif之类的都可以通过前面的魔数来进行判断文件类型，这里就以一个图片输入流转换成一个BufferedSource，并且通过 readByteString 方法拿到一个字节串 ByteString 这样就能验证这个文件是不是一个png的图片，同样的方法也能用在其他文件的校验上。
Okio除了这些外还有很多额外的功能，而且官方也提供了许多包括对于zip文件的处理，各种MD5，SHA-1.SHA256，Base64之类编码的处理，如果需要额外的一些操作，也可以自己实现Sink，Source对应的方法。

读写文件

Okio.buffer(Okio.sink(file)).writeUtf8("龙儿筝").flush();
String txt = Okio.buffer(Okio.source(file)).readUtf8();

我们在创建BufferSink和BufferSource时，先得创建Sink和Source。Sink代表输出流，Source代表输入流，所有只用一个来进行分析。
我们先看Sink代码，Sink是一个接口

public interface Sink extends Closeable, Flushable {

  void write(Buffer source, long byteCount) throws IOException;

  @Override void flush() throws IOException;

  Timeout timeout();

  @Override void close() throws IOException;
}

Sink只包含一些最简单的方法，以及一个Timeout超时，找到Sink的子类BufferedSink，发现也是一个接口，里面提供了更多的方法，再找到BufferedSick的子类Buffer和RealBufferedSink。

public static BufferedSink buffer(Sink sink) {
    return new RealBufferedSink(sink);
  }

由buffer方法可知真正创建的是RealBufferedSink。RealBufferedSink类有两个属性buffer和sink以及一些方法。

@Override public BufferedSink writeUtf8(String string, int beginIndex, int endIndex)
      throws IOException {
    if (closed) throw new IllegalStateException("closed");
    buffer.writeUtf8(string, beginIndex, endIndex);
    return emitCompleteSegments();
  }

进入writeUtf8方法可知，虽然RealBufferedSink是BufferedSink的真正实现，但写数据代理交给buffer属性来完成。buffer并不是直接将数据写入文件中，而是调用flush方法才写入文件中。

@Override public void flush() throws IOException {
    if (closed) throw new IllegalStateException("closed");
    if (buffer.size > 0) {
      sink.write(buffer, buffer.size);
    }
    sink.flush();
  }

flush方法中是由sink来完成的。由前面创建BufferedSink可知sink是Okio的sink方法创建的

Okio中的超时机制

Okio的超时机制让io不会因为异常阻塞在某个未知的错误上，Okio的基础超时机制是采用同步超时

private static Sink sink(final OutputStream out, final Timeout timeout) {
    if (out == null) throw new IllegalArgumentException("out == null");
    if (timeout == null) throw new IllegalArgumentException("timeout == null");

    return new Sink() {
      @Override public void write(Buffer source, long byteCount) throws IOException {
        checkOffsetAndCount(source.size, 0, byteCount);
        while (byteCount > 0) {
          timeout.throwIfReached();
          Segment head = source.head;
          int toCopy = (int) Math.min(byteCount, head.limit - head.pos);
          out.write(head.data, head.pos, toCopy);

          head.pos += toCopy;
          byteCount -= toCopy;
          source.size -= toCopy;

          if (head.pos == head.limit) {
            source.head = head.pop();
            SegmentPool.recycle(head);
          }
        }
      }

      @Override public void flush() throws IOException {
        out.flush();
      }

      @Override public void close() throws IOException {
        out.close();
      }

      @Override public Timeout timeout() {
        return timeout;
      }

      @Override public String toString() {
        return "sink(" + out + ")";
      }
    };
  }

这里创建Sink时传入了OutputStream和Timeout，可以看到write方法中实际上有一个while循环，在每个开始写的时候就调用了timeout.throwIfReached()方法，这个方法里面去判断时间是否超时，按序执行，同样的Source也是一样的操作。
当我们创建Sink时传入的是一个Socket对象时，会发现这里使用的是异步超时机制

public static Sink sink(Socket socket) throws IOException {
    if (socket == null) throw new IllegalArgumentException("socket == null");
    AsyncTimeout timeout = timeout(socket);
    Sink sink = sink(socket.getOutputStream(), timeout);
    return timeout.sink(sink);
  }

AsyncTimeout继承于TimeOut使用WatchDog机制来实现异步超时

Segment和SegmentPool解析

前面在while循环中写数据时会先创建一个Segment。Okio将数据分割成一块块的片段，同时segment拥有前置节点和后置节点，构成一个双向循环链表。这样采取分片使用链表，片中使用数组存储，兼具读的连续性和写的可插入性，是一种折中的方案，读写更快，而且可以根据需求改动分片的大小来权衡读写的业务操作。另外，segment也有一些内置的优化操作，综合这些Okio才能大话异彩。

Segment属性分析

final class Segment {
  static final int SIZE = 8192;

  static final int SHARE_MINIMUM = 1024;

  final byte[] data;

  int pos;

  int limit;

  boolean shared;

  boolean owner;

  Segment next;

  Segment prev;

  ...
  
}

SIZE就是一个segment的最大字节数，其中还有一个SHARE_MINIMUM，这个涉及到segment优化中的另一个技巧，共享内存，然后data就是保存的字节数组，pos，limit就是开始和结束点的index，shared和owner用来设置状态判断是否可写，一个有共享内存的segment是不能写入的，pre，next就是前置后置节点。

Segment方法分析

public void writeTo(Segment sink, int byteCount) {
    if (!sink.owner) throw new IllegalArgumentException();
    if (sink.limit + byteCount > SIZE) {
      // We can't fit byteCount bytes at the sink's current position. Shift sink first.
      if (sink.shared) throw new IllegalArgumentException();
      if (sink.limit + byteCount - sink.pos > SIZE) throw new IllegalArgumentException();
      System.arraycopy(sink.data, sink.pos, sink.data, 0, sink.limit - sink.pos);
      sink.limit -= sink.pos;
      sink.pos = 0;
    }

    System.arraycopy(data, pos, sink.data, sink.limit, byteCount);
    sink.limit += byteCount;
    pos += byteCount;
  }

owner和Shared这两个状态目前看来是完全相反的，赋值都是同步赋值的，这里有点不明白存在两个参数的意义，现在的功能主要是用来判断如果是共享就无法写，以免污染数据，会抛出异常。当然，如果要写的字节大小加上原来的字节数大于单个segment的最大值也是会抛出异常，也存在一种情况就是虽然尾节点索引和写入字节大小加起来超过，但是由于前面的pos索引可能因为read方法取出数据，pos索引后移这样导致可以容纳数据，这时就先执行移动操作，使用系统的 System.arraycopy 方法来移动到pos为0的状态，更改pos和limit索引后再在尾部写入byteCount数的数据，写完之后实际上原segment读了byteCount的数据，所以pos需要后移这么多。过程十分的清晰，比较好理解。
除了写入数据之外，segment还有一个优化的技巧，因为每个segment的片段size是固定的，为了防止经过长时间的使用后，每个segment中的数据千疮百孔，可能十分短的数据却占据了一整个segment，所以有了一个压缩机制

public void compact() {
    if (prev == this) throw new IllegalStateException();
    if (!prev.owner) return; // Cannot compact: prev isn't writable.
    int byteCount = limit - pos;
    int availableByteCount = SIZE - prev.limit + (prev.shared ? 0 : prev.pos);
    if (byteCount > availableByteCount) return; // Cannot compact: not enough writable space.
    writeTo(prev, byteCount);
    pop();
    SegmentPool.recycle(this);
  }

照例如果前面是共享的那么不可写，也就不能压缩了，然后判断前一个的剩余大小是否比当前的大，有足够的空间来容纳数据，调用前面的 writeTo 方法来写数据，写完后移除当前segment，然后通过 SegmentPool 来回收。
另一个技巧就是共享机制，为了减少数据复制带来的性能开销，segment存在一个共享机制

public Segment split(int byteCount) {
    if (byteCount <= 0 || byteCount > limit - pos) throw new IllegalArgumentException();
    Segment prefix;

    // We have two competing performance goals:
    //  - Avoid copying data. We accomplish this by sharing segments.
    //  - Avoid short shared segments. These are bad for performance because they are readonly and
    //    may lead to long chains of short segments.
    // To balance these goals we only share segments when the copy will be large.
    if (byteCount >= SHARE_MINIMUM) {
      prefix = new Segment(this);
    } else {
      prefix = SegmentPool.take();
      System.arraycopy(data, pos, prefix.data, 0, byteCount);
    }

    prefix.limit = prefix.pos + byteCount;
    pos += byteCount;
    prev.push(prefix);
    return prefix;
  }

为了防止一个很小的片段就进行共享，我们知道共享之后为了防止数据污染就无法写了，如果存在大片的共享小片段，实际上是很浪费资源的，所以通过这个对比可以看出这个最小数的意义。为了效率在移动大数据的时候直接移动整个segment而不是data，这样在写数据上能达到很高的效率

SegmentPool属性分析

final class SegmentPool {
  /** The maximum number of bytes to pool. */
  // TODO: Is 64 KiB a good maximum size? Do we ever have that many idle segments?
  static final long MAX_SIZE = 64 * 1024; // 64 KiB.

  /** Singly-linked list of segments. */
  static @Nullable Segment next;

  /** Total bytes in this pool. */
  static long byteCount;

  ...
  
}

SegmentPool实际上是Segment的对象池，这个池子的上限是64K，相当于8个segment，next这个节点可以看出这个SegmentPool是按照单链表的方式进行存储的，byteCount则是已有的大小。SegmentPool采用栈的方式来管理Segment对象。

ByteString分析

在BufferedSink中可以直接写入ByteString，ByteString是不可变的。不可变的对象有许多的好处，首先本质是线程安全的，不要求同步处理，也就是没有锁之类的性能问题，而且可以被自由的共享内部信息。

public class ByteString implements Serializable, Comparable<ByteString> {
  static final char[] HEX_DIGITS =
      { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f' };
  private static final long serialVersionUID = 1L;

  /** A singleton empty {@code ByteString}. */
  public static final ByteString EMPTY = ByteString.of();

  final byte[] data;
  transient int hashCode; // Lazily computed; 0 if unknown.
  transient String utf8; // Lazily computed.

  ...
  
}

ByteString内部有两个属性，byte数组和String，这样能够让这个类在Byte和String转换上基本没有开销，同样的也需要保存两份引用，这是明显的空间换时间的方式，为了性能Okio做了很多的事情。

Buffer分析

前面提到RealBufferedSink的操作实际上是由Buffer代理完成的。
整个Buffer持有了一个Segment的引用，通过这个引用能拿到整个链表中所有的数据。
Buffer一共实现了三个接口，读，写，以及clone。先从最简单的clone说起，clone是一种对象生成的方式，是除了常规的new·关键字以及反序列化之外的一种方式，主要分为深拷贝和浅拷贝两种，Buffer采用的是深拷贝的方式

@Override public Buffer clone() {
    Buffer result = new Buffer();
    if (size == 0) return result;

    result.head = new Segment(head);
    result.head.next = result.head.prev = result.head;
    for (Segment s = head.next; s != head; s = s.next) {
      result.head.prev.push(new Segment(s));
    }
    result.size = size;
    return result;
  }

对应实现的clone方法，如果整个Buffer的size为0，也就是没有数据，那么就返回一个新建的Buffer对象，如果不为空就是遍历所有的segment并且都创建一个对应的Segment，这样clone出来的对象就是一个全新的毫无关系的对象。前面分析segment的时候有讲到是一个双向循环链表，但是segment自身构造的时候却没有形成闭环，其实就是在Buffer中产生的。
除了clone接口外，同时还有两个接口BufferedSink，BufferedSource。Buffer实现了这两个接口的所有方法，所以既然读也有写的方法。

@Override public Buffer writeShort(int s) {
    Segment tail = writableSegment(2);
    byte[] data = tail.data;
    int limit = tail.limit;
    data[limit++] = (byte) ((s >>> 8) & 0xff);
    data[limit++] = (byte)  (s        & 0xff);
    tail.limit = limit;
    size += 2;
    return this;
  }

writeShort用来给Buffer中写入一个short的数据，首先通过writableSegment拿到一个能够有2个字节空间的segment，tail中的data就是字节数组，limit则是数据的尾部索引，写数据就是在尾部继续往后写，直接设置在data通过limit自增后的index，然后重置尾部索引，并且buffer的size大小加2。

@Override public short readShort() {
    if (size < 2) throw new IllegalStateException("size < 2: " + size);

    Segment segment = head;
    int pos = segment.pos;
    int limit = segment.limit;

    // If the short is split across multiple segments, delegate to readByte().
    if (limit - pos < 2) {
      int s = (readByte() & 0xff) << 8
          |   (readByte() & 0xff);
      return (short) s;
    }

    byte[] data = segment.data;
    int s = (data[pos++] & 0xff) << 8
        |   (data[pos++] & 0xff);
    size -= 2;

    if (pos == limit) {
      head = segment.pop();
      SegmentPool.recycle(segment);
    } else {
      segment.pos = pos;
    }

    return (short) s;
  }

读的方法相对于写的方法就复杂一些，因为buffer是分块的，读数据的过程就有可能是跨segment的，比如前面一个字节，下一个segment一个字节，这种情况就转化为readbyte，读两个字节后合成一个short对象，对于连续的读可以直接通过pos索引自增达到目的，读完后Buffer的size减2。并且会有当前的segment会出现读完后数据为null的情况，此时头部索引pos和尾部索引limit就重合了，通过pop方法可以把这个segment分离出来，并且将下一个segment设置为Buffer的head，然后将分离出来的segment回收到对象池中。

总结

Okio这个库的精髓，第一就是快，Okio采取了空间换时间的方式比如Segment和ByteString之类的存储来让IO操作尽可能不成为整个系统的瓶颈，虽然采取这种方式但是在内存上也是极致的优化，使用的片段共享以及整体的读写共享来加快大字节数组的读写，第二就是稳定，Okio提供了超时机制，不仅在IO操作上加上超时的判定，包括close，flush之类的方法中都有超时机制，这让上层不会错过一个可能导致系统崩溃的超时异常，第三就是方便，Sink，Source两个包装了写和读，区别于传统的IO各种不同的输入输出流，这里只有一种而且支持socket，十分的方便。当然Okio还有很多其他的好处，易于扩展，代码量小易于阅读，我想这就是许多上层库选择Okio来作为IO操作的原因。

参考地址

大概是最完全的Okio源码解析文章

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 206,126评论 6赞 481
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 88,254评论 2赞 382
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 152,445评论 0赞 341
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 55,185评论 1赞 278
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 64,178评论 5赞 371
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,970评论 1赞 284
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,276评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,927评论 0赞 259
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,400评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,883评论 2赞 323
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,997评论 1赞 333
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,646评论 4赞 322
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,213评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,204评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,423评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,423评论 2赞 352
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,722评论 2赞 345