Java程序CPU使用率过高问题排查与修复

　　问题现象：CPU负载过高
　　我们线上的java系统，时不时会发生CPU负载过高的现象。问题排查
　　应对Java程序导致的CPU使用率过高这一问题，GitHub上有现成的解决方案：showbusyjavathreads。https：github。comoldratleeusefulscriptswgetnocheckcertificatehttps：github。comoldratleeusefulscriptsarchiverelease2。x。zipunziprelease2。x。zip
　　登录上机器，在CPU使用率高时候，执行showbusyjavathreads脚本。showbusyjavathreads
　　摘选其中的一些输出如下：Thestackofbusy（25。0）thread（202390x4f0f）ofjavaprocess（248927）ofuser（jenkins）：HandlingGETjobjenkinstestjobapijsonfrom172。168。1。1：qtp164180884631273127prio5osprio0tid0x00007f7380014000nid0x4f0frunnable〔0x00007f722c392000〕java。lang。Thread。State：RUNNABLEatjava。util。Arrays。copyOfRange（Arrays。java：3664）atjava。lang。String。init（String。java：207）atjava。lang。String。substring（String。java：1933）atnet。sf。json。util。JSONTokener。matches（JSONTokener。java：110）atnet。sf。json。JSONObject。fromJSONTokener（JSONObject。java：912）atnet。sf。json。JSONObject。fromObject（JSONObject。java：156）atnet。sf。json。util。JSONTokener。nextValue（JSONTokener。java：348）atnet。sf。json。JSONArray。fromJSONTokener（JSONArray。java：1131）atnet。sf。json。JSONArray。fromObject（JSONArray。java：125）atnet。sf。json。util。JSONTokener。nextValue（JSONTokener。java：351）atnet。sf。json。JSONObject。fromJSONTokener（JSONObject。java：955）atnet。sf。json。JSONObject。fromObject（JSONObject。java：156）atnet。sf。json。util。JSONTokener。nextValue（JSONTokener。java：348）atnet。sf。json。JSONObject。fromJSONTokener（JSONObject。java：955）atnet。sf。json。JSONObject。fromObject（JSONObject。java：156）atnet。sf。json。util。JSONTokener。nextValue（JSONTokener。java：348）atnet。sf。json。JSONObject。fromJSONTokener（JSONObject。java：955）atnet。sf。json。JSONObject。fromObject（JSONObject。java：156）atnet。sf。json。util。JSONTokener。nextValue（JSONTokener。java：348）atnet。sf。json。JSONObject。fromJSONTokener（JSONObject。java：955）atnet。sf。json。JSONObject。fromString（JSONObject。java：1145）atnet。sf。json。JSONObject。fromObject（JSONObject。java：162）atnet。sf。json。JSONObject。fromObject（JSONObject。java：132）atsam。Sam。sendRequestReturnJson（Sam。java：517）atsam。Sam。getPermissionByUser（Sam。java：225）atsam。Sam。checkUserPermissionLocal（Sam。java：243）atcom。michelin。cio。hudson。plugins。rolestrategy。PermissionCache。getPermissionSam（RoleMap。java：155）atcom。michelin。cio。hudson。plugins。rolestrategy。PermissionCache。getPermission（RoleMap。java：106）atcom。michelin。cio。hudson。plugins。rolestrategy。RoleMap。hasPermission（RoleMap。java：220）atcom。michelin。cio。hudson。plugins。rolestrategy。RoleMap。access000（RoleMap。java：166）atcom。michelin。cio。hudson。plugins。rolestrategy。RoleMapAclImpl。hasPermission（RoleMap。java：569）athudson。security。SidACL。hasPermission（SidACL。java：70）
　　从上面的输出可以看到，25。0的CPU资源在处理HandlingGET
　　jobjenkinstestjobapijsonfrom172。168。1。1这个请求。
　　运维同学根据这个ip，定位到发起请求的是某同学A。这个同学在跑一些定时任务，定时拉取job的执行结果。
　　问题是当我直接访问这个接口：
　　jobjenkinstestjobapijson时，返回并不慢，几乎很快就可以返回。问题应该不是这个接口的问题。
　　我们接着从。showbusyjavathreads输出往下看：看到其中有问题的调用栈：atnet。sf。json。JSONObject。fromObject（JSONObject。java：132）atsam。Sam。sendRequestReturnJson（Sam。java：517）atsam。Sam。getPermissionByUser（Sam。java：225）atsam。Sam。checkUserPermissionLocal（Sam。java：243）
　　看起来是这个Sam校验用户权限导致的CPU使用率过高，而接着看上面的代码
　　net。sf。json。JSONObject。fromObject，这个是在做json的反序列化。
　　通常来说，json的序列化、反序列化都是比较费CPU的，更糟糕的是，这里用到的json序列化框架是net。sf。json，而不是Java常用的jackson和gson等。
　　直觉告诉我，肯定是这个net。sf。json反序列化引起的CPU使用率过高问题。
　　备注：
　　通过跟之前维护jenkins的同学了解到，他们基于rolestrategy插件，重写了jenkins权限验证逻辑，用的就是Sam权限。翻看sam权限插件的代码，确实有用net。sf。json做json反序列化。
　　到这里，定位到大概率是Sam权限插件的net。sf。json反序列化引起的问题。问题复现
　　为了验证这个问题，我们拿到Sam权限插件的代码。找到出问题的关键代码：publicvoidgetPermissionByUser（Stringemail）｛JSONObjectparamsnewJSONObject（）；params。put（useremail，email）；params。put（subsystemid，SAMJENKINSSUMSYSTEMID）；JSONObjectressendRequestReturnJson（URL，GET，params）；if（res。get（success）。equals（true））｛cacheUserPermission（params。getString（useremail），res。getJSONObject（permission）。getJSONObject（email）。getJSONObject（SERVICE））；｝｝publicstaticJSONObjectsendRequestReturnJson（Stringendpoint，Stringmethod，JSONObjectparams）｛if（method。equals（POST））｛returnJSONObject。fromObject（sendPostRequest（endpoint，params））；｝elseif（method。equals（GET））｛returnJSONObject。fromObject（sendGetRequest（endpoint，params））；｝returnnewJSONObject（）；｝
　　可以看到，这段代码会根据用户邮箱，发送http请求调用Sam系统，获取用户的权限数据，然后将数据反序列化成JSONObject，即：JSONObject。fromObject（sendGetRequest（endpoint，params，token））
　　在本地，通过复现A同学的请求，发现这个请求确实比较慢，而且费CPU。通过debug得知，这个用户返回的json数据有1M左右，json反序列化CPU打满。
　　而通过其他用户请求，发现处理很快，返回的json数据也比较小。
　　到这里，确认就是net。sf。json框架的反序列化性能问题，引起的CPU使用率过高。我们需要替换成其他高性能的json序列化框架。
　　备选有：gson、jackson、fastjson等。fastjson因为经常出安全漏洞，暂不考虑，我们考虑从gson、jackson选择一个。替换成gson
　　将之前的代码替换成gson，代码如下：publicvoidgetPermissionByUser（Stringemail）｛JSONObjectparamsnewJSONObject（）；params。put（useremail，email）；params。put（subsystemid，SAMJENKINSSUMSYSTEMID）；JsonObjectressendRequestReturnJsonV2（URL，GET，params）；if（res。get（success）。getAsBoolean（））｛cacheUserPermission（params。getString（useremail），res。getAsJsonObject（permission）。getAsJsonObject（email）。getAsJsonObject（SERVICE））；｝｝publicstaticJsonObjectsendRequestReturnJsonV2（Stringendpoint，Stringmethod，JSONObjectparams）throwsIOException｛if（method。equals（POST））｛returnGSON。fromJson（sendPostRequest（endpoint，params，token），JsonObject。class）；｝elseif（method。equals（GET））｛returnGSON。fromJson（sendGetRequest（endpoint，params，token），JsonObject。class）；｝returnnewJsonObject（）；｝
　　重新编译权限插件后上线，再次查看CPU负载监控，发现CPU负载确实降下来了（0513晚上0点左右上线的）。