共计 5917 个字符，预计需要花费 15 分钟才能阅读完成。
作者：vivo 互联网服务器团队 - Chen Dongxing、Li Haoxuan、Chen Jinxia
随着业务的日渐简单，性能优化俨然成为了每一位技术人的必修课。性能优化从何着手？如何从问题表象定位到性能瓶颈？如何验证优化措施是否无效？本文将介绍分享 vivo push 举荐我的项目中的性能调优实际，心愿给大家提供一些借鉴和参考。
一、背景介绍
在 Push 举荐中，线上服务从 Kafka 接管须要触达用户的事件，之后为这些指标用户选出最合适的文章进行推送。服务由 Java 开发，CPU 密集计算型。
随着业务的一直倒退，申请并发及模型计算量越来越大，导致工程上遇到了性能瓶颈，Kafka 生产呈现重大的积压景象，无奈及时实现指标用户的散发，业务增长诉求得不到满足，故亟需进行性能专项优化。
二、优化掂量指标和思路
咱们的性能掂量指标是吞吐量 TPS，由经典公式 TPS = 并发数 / 均匀响应工夫 RT 能够晓得，若需进步 TPS，能够有 2 种形式：
- 进步并发数，比方晋升单机的并行线程数，或者横向扩容机器数；
- 升高均匀响应工夫 RT，包含利用线程（业务逻辑）执行工夫，以及 JVM 自身的 GC 耗时。
理论状况中，咱们的机器 CPU 利用率曾经很高，达到 80% 以上，晋升单机并发数的预期收益无限，故把次要精力投入到升高 RT 上。
上面将从 热点代码 和 JVM GC 两个方面进行详解，咱们如何剖析定位到性能瓶颈点，并应用 3 招将吞吐量晋升 100%。
三、热点代码优化篇
如何疾速找到利用中最耗时的热点代码呢？借助阿里巴巴开源的 arthas 工具，咱们获取到线上服务的 CPU 火焰图。
火焰图阐明：火焰图是基于 perf 后果产生的 SVG 图片，用来展现 CPU 的调用栈。
y 轴示意调用栈，每一层都是一个函数。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。
x 轴示意抽样数，如果一个函数在 x 轴占据的宽度越宽，就示意它被抽到的次数多，即执行的工夫长。留神，x 轴不代表工夫，而是所有的调用栈合并后，按字母顺序排列的。
火焰图就是看顶层的哪个函数占据的宽度最大。只有有“平顶”（plateaus），就示意该函数可能存在性能问题。
色彩没有非凡含意，因为火焰图示意的是 CPU 的忙碌水平，所以个别抉择暖色调。
3.1 优化 1：尽量避免原生 String.split 办法
3.1.1 性能瓶颈剖析
从火焰图中，咱们首先发现了有 13% 的 CPU 工夫花在了 java.lang.String.split 办法上。
相熟性能优化的同学会晓得，原生 split 办法是性能杀手，效率比拟低，频繁调用时会消耗大量资源。
不过业务上特色解决时的确须要频繁地 split，如何优化呢？
通过剖析 split 源码，以及我的项目的应用场景，咱们发现了 3 个优化点：
（1）业务中未应用正则表达式，而原生 split 在解决分隔符为 2 个及以上字符时，默认按正则表达式形式解决；家喻户晓，正则表达式的效率是低下的。
（2）当分隔符为单个字符（且不为正则表达式字符）时，原生 String.split 进行了性能优化解决，但两头有些外部转换解决，在咱们的理论业务场景中反而是多余的、耗费性能的。
其 具体实现 是：通过 String.indexOf 及 String.substring 办法来实现宰割解决，将宰割后果存入 ArrayList 中，最初将 ArrayList 转换为 string[] 输入。而咱们业务中，其实很多时候须要 list 型后果，多了 2 次 list 和 string[] 的互转。
（3）业务中调用 split 最频繁的中央，其实只须要 split 后的第 1 个后果；原生 split 办法或其它工具类有重载优化办法，能够指定 limit 参数，满足 limit 数量后能够提前返回；但业务代码中，应用 str.split(delim)[0] 形式，非性能最佳。
3.1.2 优化计划
针对业务场景，咱们自定义实现了性能优化版的 split 实现。
import java.util.ArrayList;
import java.util.List;
import org.apache.commons.lang3.StringUtils;
/**
* 自定义 split 工具
*/
public class SplitUtils {
/**
* 自定义宰割函数，返回第一个
*
* @param str 待宰割的字符串
* @param delim 分隔符
* @return 宰割后的第一个字符串
*/
public static String splitFirst(final String str, final String delim) {if (null == str || StringUtils.isEmpty(delim)) {return str;}
int index = str.indexOf(delim);
if (index < 0) {return str;}
if (index == 0) {
// 一开始就是分隔符，返回空串
return "";
}
return str.substring(0, index);
}
/**
* 自定义宰割函数，返回全副
*
* @param str 待宰割的字符串
* @param delim 分隔符
* @return 宰割后的返回后果
*/
public static List<String> split(String str, final String delim) {if (null == str) {return new ArrayList<>(0);
}
if (StringUtils.isEmpty(delim)) {List<String> result = new ArrayList<>(1);
result.add(str);
return result;
}
final List<String> stringList = new ArrayList<>();
while (true) {int index = str.indexOf(delim);
if (index < 0) {stringList.add(str);
break;
}
stringList.add(str.substring(0, index));
str = str.substring(index + delim.length());
}
return stringList;
}
}相比原生 String.split，次要有几方面的改变：
- 放弃正则表达式的反对，仅反对按分隔符进行 split；
- 出参间接返回 list。宰割解决实现，与原生实现中针对单字符的解决相似，应用 string.indexOf 及 string.substring 办法，宰割后果放入 list 中，出参间接返回 list，缩小数据转换解决；
- 提供 splitFirst 办法，业务场景只须要分隔符前第一段字符串时，进一步晋升性能。
3.1.3 微基准测试
如何验证咱们的优化成果呢？首先选用 jmh 作为 微基准测试工具，对照选用 原生 String.split 以及 apache 的 StringUtils.split 办法，测试后果如下：
选用单字符作为分隔符
能够看出，原生实现与 apache 的工具类性能差不多，而自定义实现性能晋升了约 50%。
选用多字符作为分隔符
当分隔符应用 2 个长度的字符时，原始实现的性能大幅升高，只有单 char 时的 1/3；而 apache 的实现也升高至原来的 2/3，而自定义实现与原来根本保持一致。
选用单字符作为分隔符，只需返回第 1 个宰割后果
选用单字符作为分隔符，并只需第 1 个宰割后果时，自定义实现的性能是原生实现的 2 倍，并是取原生实现残缺后果的 5 倍。
3.1.4 端到端优化成果
经微基准测试验证收益后，咱们将优化部署到在线服务中，验证端到端整体的性能收益；
从新应用 arthas 采集火焰图，split 办法耗时升高至 2% 左右；端到端整体耗时 降落了 31.77%，吞吐量 上涨了 45.24%，性能收益特地显著。
3.2 优化 2：放慢 map 的查表效率
3.2.1 性能瓶颈剖析
从火焰图中，咱们发现 HashMap.getOrDefault 办法耗时占比也特地多，达到了 20%，次要在查问权重 map 上，这是因为：
- 业务中的确需高频调用，特色穿插解决后数量收缩，单机的调用并发达到了约 1000w ops/s。
- 权重 map 自身也很大，存储了 1000 万多的 entry，占用了很大一块内存；同时 hash 碰撞的概率也增大，碰撞时的查问效率由 O(1) 升高成了 O(n)（链表）或 O(logn)（红黑树）。
Hashmap 自身是十分高效的 map 实现，起初咱们尝试了调整加载因子 loadFactor 或 换用其它 map 实现，均未获得显著收益。
如何能力晋升 get 办法的性能呢？
3.2.2 优化计划
剖析过程中咱们发现查问 map 的 key（穿插解决后的特色 key）是字符串型，且均匀长度在 20 以上；咱们晓得 string 的 equals 办法其实是遍历比对 char[] 中的字符，key 越长则比对效率越低。
public boolean equals(Object anObject) {if (this == anObject) {return true;}
if (anObject instanceof String) {String anotherString = (String)anObject;
int n = value.length;
if (n == anotherString.value.length) {char v1[] = value;
char v2[] = anotherString.value;
int i = 0;
while (n-- != 0) {if (v1[i] != v2[i])
return false;
i++;
}
return true;
}
}
return false;
}是否能够将 key 的长度缩短，或者甚至换成数值型？通过简略的微基准测试，咱们发现思路应该是可行的。
于是与算法同学沟通，巧的是算法同学正好也有雷同诉求，他们在切换新训练框架过程中发现 string 的效率特地低，须要把特色换成数值型。
一拍即合，计划很快确定：
- 算法同学将特色 key 映射成 long 型数值，映射办法为自定义的 hash 实现，尽量减少 hash 碰撞概率；
- 算法同学训练输入新模型的权重 map，能够保留更多 entry，以打平基线模型的成果指标；
- 打平基线模型的成果指标后，在线服务端灰度新模型，权重 map 的 key 改用 long 型，验证性能指标。
3.2.3 优化成果
在减少了 30% 的特色 entry 数下（模型成果超过基线），工程上的性能也达到了显著收益；
端到端整体耗时 降落了 20.67%，吞吐量 上涨了 26.09%；此外内存应用上也获得了良好收益，权重 map 的内存大小 降落了 30%。
四、JVM GC 优化篇
Java 设计垃圾主动回收的目标是将应用程序开发人员从手动动态内存治理中解放出来。开发人员无需关怀内存的调配与回收，也不必关注调配的动态内存的生存期。这齐全打消了一些与内存治理相干的谬误，代价是减少了一些运行时开销。
在小型零碎上开发时，GC 的性能开销能够疏忽，但扩大到大型零碎（尤其是那些具备大量数据、许多线程和高事务率的应用程序）时，GC 的开销不可漠视，甚至可能成为重要的性能瓶颈。
上图 模仿了一个现实的零碎，除了垃圾收集之外，它是齐全可伸缩的。红线示意在单处理器零碎上只破费 1% 工夫进行垃圾收集的应用程序。这意味着在领有 32 个处理器的零碎上，吞吐量损失超过 20%。洋红色线显示，对于垃圾收集工夫为 10% 的应用程序(在单处理器应用程序中，垃圾收集工夫不算太长)，当扩大到 32 个处理器时，会损失 75% 以上的吞吐量。
故 JVM GC 也是很重要的性能优化措施。
咱们的举荐服务应用高配计算资源（64 核 256G），GC 的影响因素挺可观；通过采集监控在线服务 GC 数据，发现咱们的服务 GC 状况挺蹩脚的，每分钟 YGC 累计耗时约 10s。
GC 开销为何这么大，如何升高 GC 的耗时呢？
4.1 优化 3：应用堆外缓存代替堆内缓存
4.1.1 性能瓶颈剖析
咱们 dump 了服务的存活堆对象，应用 mat 工具进行内存剖析，发现有 2 个对象特地微小，占了总存活堆内存的 76.8%。其中：
- 第 1 大对象是本地缓存，存储了细粒度级别的罕用数据，每台机器千万级别数据量；应用 caffine 缓存组件，缓存主动刷新周期设定 1 小时；目标是尽量减少 IO 查问次数；
- 第 2 大对象是模型权重 map 自身，常驻内存中，不会 update，等新模型载入后被作为旧模型进行卸载。
4.1.2 优化计划
如何能尽量缓存较多的数据，同时防止过大的 GC 压力呢？
咱们想到了把缓存对象移到堆外，这样能够不受堆内内存大小的限度；并且堆外内存，并不受 JVM GC 的管控，防止了缓存过大对 GC 的影响。通过调研，咱们决定采纳成熟的开源堆外缓存组件 OHC。
（1）OHC 介绍
简介
OHC 全称为 off-heap-cache，即堆外缓存，是 2015 年针对 Apache Cassandra 开发的缓存框架，起初从 Cassandra 我的项目中独立进去，成为独自的类库，其我的项目地址为 https://github.com/snazy/ohc。
个性
- 数据存储在堆外，只有大量元数据存储堆内，不影响 GC
- 反对为每个缓存项设置过期工夫
- 反对配置 LRU、W_TinyLFU 驱赶策略
- 可能保护大量的缓存条目
- 反对异步加载缓存
- 读写速度在微秒级别
（2）OHC 用法
疾速开始：
OHCache ohCache = OHCacheBuilder.newBuilder().
keySerializer(yourKeySerializer)
.valueSerializer(yourValueSerializer)
.build();可选配置项：
在咱们的服务中，设置 capacity 容量 12G，segmentCount 分段数 1024，序列化协定应用 kryo。
4.1.3 优化成果
切换到堆外缓存后，服务 YGC 升高到了 800ms / 每分钟，端到端的整体吞吐量上涨了约 20%。
4.2 思考题
在 Java GC 优化中，咱们把本地缓存对象从 Java 堆内移到了堆外，获得了不错的性能收益。还记得上文提到的另一个巨型对象，模型权重 map 吗？模型权重 map 是否也从 Java 堆内移除？
答案是能够的。咱们应用 C ++ 改写了模型推理计算局部，包含权重 map 的存储与检索、排序得分计算等逻辑；而后将 C ++ 代码输入为 so 库文件，Java 程序通过 native 形式调用，实现将权重 map 从 Jvm 堆内移出，取得了很好的性能收益。
五、结束语
通过上文介绍的 3 个措施，咱们从 热点代码优化 与 Jvm GC 两方面改善了服务负载与性能，整体吞吐量翻了 1 倍，达到了阶段性的预期指标。
不过性能调优是永无止境的，而且每个业务场景、每个零碎的理论状况也都是千差万别，很难用 1 篇文章去涵盖介绍所有的优化场景。心愿本文介绍的一些调优实战经验，比方如何确定优化方向、如何着手剖析以及如何验证收益，能给大家一些借鉴和参考。