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数组也需要占用相应大小的内存空间，关键是这种自动转换很多时候是徒劳的，原因有二：
- 如果响应体中的数据本身就是二进制的，比如文件下载，则系统还需要从字符串转回byte数组
- 自动转换固定采用了ISO-8859-1字符集，该字符集在很多国家和地区并不能满足当地的文字编码需求，东亚字符更是如此，因此需要将ISO字符串转回byte数组，之后再转换成对应字符集的字符串，比如UTF-8
jodd为什么要使用字符串存储响应体数据，目前尚未可知，但有一个比较明显的好处是，在使用ISO-8859-1字符集的系统中，该方式可以避免存放响应体二进制数据的额外内存占用。
通过对以上两个实现细节的分析，在使用jodd时还需考虑具体的应用场景，避免引起不必要的内存和性能问题。
文末彩蛋
在将响应体数据转换为字符串时，jodd为什么选择了ISO-8859-1字符集，而不是其他字符集呢？
ISO-8859-1是一种基础字符集，包含的字符都是单字节编码，取值范围是0x00~0xFF，一共256个编码。因此，该字符集天然具备一种特性，任何的二进制值都能转换成相应的字符编码。也就是说，如果采用了该字符集，任何二进制数据都可以和ISO字符串之间进行无损的双向转换。jodd正是利用了这种性质巧妙地实现了使用字符串存储响应体并且不会丢失数据。
