jodd-http实现细节的一点思考

  jodd-http是一个很是轻巧的http客户端工具，使用起来简单便利、容易上手。常见的http请求方式都能很好地支持，包括文件的上传下载、chunk响应模式，还必定程度上支持长连接、模拟浏览器、隧道等特性。下文中将使用jodd指代jodd-http。

   最近部门有个项目使用该技术实现了一个轻量级的网关代理层，前几天在和帅哥排查问题时注意到jodd实现上的两个细节，若使用不当会致使服务端的性能和内存空间方面产生问题。

第一，jodd自动处理chunk响应会形成内存开销较大

  在处理服务端的chunk响应时，jodd采用自循环的方式，直到接收彻底部数据为止（见代码一）。假设系统须要处理不少大响应体的请求时，这种方式便会占用过多的内存空间，甚至有OOM的风险。另外，衡量web性能的众多指标中有一个叫作TTFB的重要指标，即 Time To First Byte，它表示客户端自请求发出直至接收到响应的第一个字节时所经历的时间延迟，显然，在网关代理层的场景中，jodd拼装好完整响应后再返回给客户端的时间消耗会对该指标产生较大的不利影响。

// 如下是jodd.http.HttpBase#readBody方法中的读取chunk数据的代码段
if (isChunked) {
   FastCharArrayWriter fastCharArrayWriter = new FastCharArrayWriter();
   try {
      while (true) {
         String line = reader.readLine();
         int len = Integer.parseInt(line, 16);
         if (len > 0) {
            StreamUtil.copy(reader, fastCharArrayWriter, len);
            reader.readLine();
         } else {
            // end reached, read trailing headers, if there is any
            readHeaders(reader);
            break;
         }
      }
   } catch (IOException ioex) {
      throw new HttpException(ioex);
   }
   bodyString = fastCharArrayWriter.toString();
}
复制代码

代码一

第二，jodd会自动将响应体中原始的byte数组转换成字符串（见代码二），该操做不少时候会形成没必要要的资源浪费

// 在jodd.http.HttpBase#readBody方法中，使用以下语句从包装了输入流的Reader中读取字符数据至Writer中
StreamUtil.copy(reader, fastCharArrayWriter, contentLenValue);
复制代码

代码二

  首先这种转换操做须要进行CPU运算，其次，转换结果的char数组也须要占用相应大小的内存空间，关键是这种自动转换不少时候是徒劳的，缘由有二：

1. 若是响应体中的数据自己就是二进制的，好比文件下载，则系统还须要从字符串转回byte数组

2. 自动转换固定采用了ISO-8859-1字符集，该字符集在不少国家和地区并不能知足当地的文字编码需求，东亚字符更是如此，所以须要将ISO字符串转回byte数组，以后再转换成对应字符集的字符串，好比UTF-8

  jodd为何要使用字符串存储响应体数据，目前还没有可知，但有一个比较明显的好处是，在使用ISO-8859-1字符集的系统中，该方式能够避免存放响应体二进制数据的额外内存占用。

  经过对以上两个实现细节的分析，在使用jodd时还需考虑具体的应用场景，避免引发没必要要的内存和性能问题。

文末彩蛋

  在将响应体数据转换为字符串时，jodd为何选择了ISO-8859-1字符集，而不是其余字符集呢？

  ISO-8859-1是一种基础字符集，包含的字符都是单字节编码，取值范围是0x00~0xFF，一共256个编码。所以，该字符集自然具有一种特性，任何的二进制值都能转换成相应的字符编码。也就是说，若是采用了该字符集，任何二进制数据均可以和ISO字符串之间进行无损的双向转换。jodd正是利用了这种性质巧妙地实现了使用字符串存储响应体而且不会丢失数据。