在使用TCP协议作为传输协议时，很多时候都需要输出原始报文用来查看传输数据是否正确。特别是在物联网中的硬件服务器，上下行的数据量非常大，任何关于报文的处理的开销都会因为消息的增加而成倍放大。
不管使用ByteArray或者ByteBuffer当做数据容器，输出日志时，都需要进行两步，第一步：把字节数组的字节转成字符；第二步：在拼接字符形成字符串。
一般的处理方式
迭代拼接字符串
创建StringBuilder，迭代ByteArray，格式化每个byte后，追加到StringBuilder中，最后使用StringBuilder.toString()方法输出完整字符串。
/**
* 根据字节数组，输出对应的格式化字符串
* @param bytes 字节数组
* @return 字节数组字符串
*/
public static String printBytesByStringBuilder(byte[] bytes){
StringBuilder stringBuilder = new StringBuilder();
for (byte aByte : bytes) {
stringBuilder.append(byte2String(aByte));
}
return stringBuilder.toString();
}
public static String byte2String(byte b){
return String.format("%02x ",b);
}
特定优化处理
预分配字符数组，使用常量池来实现字节到字符的转换。填充提前预分配好的字符数组。输出字符串！
第一步：穷举所有byte对应的字符数组
穷举所有的byte对应的两位字符
第二步：使用索引的方式进行字符串拼接
/**
* 使用字符数组进行byte字节信息的输出 如果默认进制标识的话，不打印'0x',一个byte只需要两个char 例如： 0x9 = '0' + '9' 0xAF = 'A' + 'F'
* 0x9 0xAF = > '0'+'9'+' '+'A'+'F'
* <p>
* 一个byte需要2个字符标识，外加一个空格字符
*
* @param bytes 需要格式化的byte
* @return 字节数组 字符串
*/
public static String printBytesByCharPool(byte[] bytes) {
int byteLength = bytes.length;
int charLength = byteLength * 3;
char[] content = new char[charLength];
int unsignedByte = 0;
int startIndex = 0;
for (int i = 0; i < byteLength; i++) {
// 使byte变为无符号的byte
// b2u
unsignedByte = ((int) bytes[i]) & 0xFF;
char[] chars = BYTE_CHARS[unsignedByte];
startIndex = i * 3;
// byte的第一位字符
content[startIndex] = chars[0];
// byte格式化的第二位字符
content[startIndex + 1] = chars[1];
// 尾随的空格字符
content[startIndex + 2] = WHITE_CHAR;
}
return new String(content);
}
分别使用1024长度的byteArray进行循环1200次打印结果：
# 使用stringBuilder
printBytesByStringBuilder useTime=1070
# 使用字符池
printBytesByCharPool useTime=4
可以看出来速度差别在两个数量级
其他开销分析
分析这两种方法存在的性能开销点有：String.format的性能，StringBuilder的性能
String.format
String.format方法用来格式化代码，进入源码可以看到，每次都会创建一个模板对象，不能复用，这个必然存在一定的性能开销
public static String format(String format, Object... args) {
return new Formatter().format(format, args).toString();
}
StringBuilder的性能
虽然StringBuilder 已经是最常用的字符串拼接方法，如果频繁调用也会发现内部其实也有动态扩容的机制，类似于hasmap的扩容。当容量没有预估时，会发生多次动态扩容。
使用场景
在用于做Tcp服务器时，客户端与服务端使用Tcp长连接进行通讯，需要输出原始报文进行信息查看和追踪，这个时候输出报文的开销就伴随这设备增多会成倍放大，关于输出Tcp中报文字节的开销就不能小视。
如果是次场景优化，其他可以采取的方法有：
- 尽量使用定长协议，可以提前分割定长协议的格式化所需要内存空间
- 如果在输出字节数组时，需要增加前缀或者后缀，也可以在申请字节数组对应的字符数组时提前把前后缀的内容对应的空间一起创建出来
- 如果消息量特别大时也可以考虑使用队列进行延迟或异步打印，不影响网络吞吐
