高性能 Java 计算服务的性能调优实战

随着业务的日渐复杂，性能优化俨然成为了每一位技术人的必修课。性能优化从何着手？如何从问题表象定位到性能瓶颈？如何验证优化措施是否有效？本文将介绍分享 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[] 输出。而我们业务中，其实很多时候需要 l