JVM(和Spark)性能优化：使用Java Mission Control (4)

3.2 真实的业务案例

在一般信息-JVM信息-Java应用程序参数中可以看到Spark的执行器后端，executor id为4、主机为SR2S1、分配的cores、workerUrl:

org.apache.spark.executor.CoarseGrainedExecutorBackend akka.tcp://sparkDriver@SR1S3:23718/user/CoarseGrainedScheduler 4 SR2S1 24 application_1422534342886_0019

转储出的jfr文件可能较大，超过100M，如果出现这个问题，需要加大jmc.ini的内存：

-startup
../lib/missioncontrol/plugins/org.eclipse.equinox.launcher_1.3.0.v20120522-1813.jar
--launcher.library
../lib/missioncontrol/plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.200.v20120913-144807
-vm
./javaw.exe
-vmargs
-XX:+UseG1GC
-Xmx1024m
-Xms1024m
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder
-Djava.net.preferIPv4Stack=true

3.2.1 热点方法

无线OSS开发部是公司大规模使用Spark较早的团队，用于手机用户数据流量等的分析。在后来的开发过程中也使用JMC来度量应用程序性能瓶颈。
例如，通过JMC的代码->热点方法，高海涛发现解析的时候read4ByteLong和read8ByteLong占用时间时间很长，代码实现可以优化：

堆栈跟踪 样本计数 百分比(%)
java.lang.Integer.toString(int) 1,237 2.574
java.lang.String.valueOf(int) 1,237 2.574
com.huawei.pai.parser.WlbinInputStream.byte4ToLong(byte[], int) 649 1.351
com.huawei.pai.parser.WlbinInputStream.read4ByteLong() 649 1.351
com.huawei.pai.parser.ugwufdr.ufdrassociate2.ufdr.Parser_Struct_VOLUME.parse(WlbinInputStream, int) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.ufdr.Parser_TLVGroup_UFDR_UFDR.parse(WlbinInputStream, int, Parser_UFDR) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.ufdr.Parser_UFDR.parse(WlbinInputStream, int) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.Parser_UGWUFDR_Union.parse(WlbinInputStream, int, int) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.Parser_Struct_UGWUFDR_Log.parse(WlbinInputStream, int, int) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.Parser_UGWUFDR.parse(WlbinInputStream) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.Parser_Root.parse(WlbinInputStream) 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.Parser_Root_Adapter.parseToAdapters(WlbinInputStream) 422 0.878
com.huawei.pai.parser.adapter.WlbinUfdrRecordReaderAdapter.parsePkg(String, byte[], int) 422 0.878
com.huawei.pai.parser.adapter.WlbinAbstractRecordReaderAdapter.nextKeyValue() 422 0.878
com.swimap.prs.paiplugin.common.io.input.SequenceFileReaderBase.tryCacheNext() 422 0.878
com.swimap.prs.paiplugin.common.io.input.SequenceFileReaderBase$$anon$1.hasNext() 422 0.878
com.huawei.pai.parser.ugwufdr.ufdrassociate2.ufdr.Parser_Struct_TIME.parse(WlbinInputStream, int) 160 0.333
com.huawei.pai.parser.ugwufdr.ufdrassociate2.ufdr.Parser_UFDR.parse(WlbinInputStream, int) 67 0.139
com.huawei.pai.parser.WlbinInputStream.byte8ToLong(byte[], int) 588 1.224

高海涛还发现，类APP_BLOCKCAUSE_SUBS_Key的compareTo调用次数多，这两个字段（base_imsi和base_msisdn）都参与比较了，base_msisdn应该可以省略。Key对象的compareTo是系统中掉用次数最多的方法。所有Key对象的compareTo函数中，最后一个属性如果是数值类型，应该用减法，比较操作和减法操作的代价是相同的，改为减法后代价从2变成1。如果是字符串类型只应该调用一次属性的compareTo方法。

if (this.uli_flag < that.uli_flag) {
return -1;
} else if (this.uli_flag > that.uli_flag) {
return 1;
}
return 0;

可修改成 ：this.uli_flag - that.uli_flag
发现一个问题，我们代码中所有Key对象重载过的hashCode方法被删除了。
我觉得这里不应该删除。每个Key对象的hashCode在reduce阶段会被调用多次，我们在这个方法上做过性能优化。

之前做过的优化：
1. 可配置哪些字段计算hashCode。我们重载的方法比默认的（使用所有字段计算）计算速度更快。
2. 存储计算过的hashCode值，Key对象的hashCode只计算一次，可使用多次。因为每次hashCode的计算需要多次乘法和加法操作，若只执行一次可显著减少执行时间。

我们内部存储对象使用的是TreeMap，TreeMap是个二叉树结构，每个对象put到TreeMap时都会多次调用compareTo方法，我们可以在compareTo方法上可以做进一步的优化。很多Key对象的字段较多，或有比较操作代价较大的字段（如String类型），这些类尤其需要优化。方法：建议所有Key存储一个hashCode值（只需计算一次），hashCode作为第一个字段参与compareTo计算，因绝大部分对象的hashCode值不同，这样绝大部分compareTo操作在第一个条件判断就返回，可显著减少计算量。