Java 程序该怎么优化？实战篇
面试官： 出现了性能问题，该怎么去排查呢？
程序猿： 接口响应那么慢，时间都花到哪里去了？
运维喵： 为什么你的应用跑着跑着，CPU 就接近 100%？
分享一些真实生产问题排查故事，看看能否涨姿势，能否 get 到其中之「趣」？
另外，为了方便收藏，文末把 Java 程序优化及问题排查套路， 整理成了葵 花宝 典 ，一定要记得收藏呦。
1.
业务催的急，心发慌的现场！
2012 年，在一家支付公司做用户域的基础服务，每天做的事儿便是为满足业务需求，制定各种各样的 API。
某天，业务反馈线上调用查询省份地市接口频繁超时 ... ...
生产要敬畏，生产无小事。
于是乎，煎饼果子丢一旁。 一边让业务同事提供调用接口时的唯一 ID（rpid，查询日志全靠它），一边 找运维同事 确认网络有没有问题、服务有没有问题，在排除环境没问题的前提下，快速根据 rpid 获取日志并进行分析 。
日志记得好，排查问题没烦恼。 发现程序执行到访问数据库拿数据时总会需要花费很长时间，导致业务接口超时。
当时，分析原因有二。
原因 一： 大部分接口都是读在线库，而 该 接 口 读的则是离 线 库，但是 离线库配置的最大连接数 是 2 ， 在 高并发情况下，拿不到数据库连接 ；
原因二： 省份地市信 息为不变信息，程序并 没有 借助 缓存 提升性能 。
寻得病症，便可对症下药。
2.
服务一启动，运维就疯狂打 Call 的现场。
2016 年，在一家互联网金融公司负责理财网站的从 0 到 1，都知道要想服务做的好，监控模块少不了。
当时时间紧任务重，分工也很明确，有两个兄弟负责监控模块的搭建，测试验证通过后，进行上线，但是只要一启动监控模块，运维同事都反馈机器 CPU 疯狂报警。
生产要敬畏，生产无小事。
于是，带着做监控模块的兄弟开启了排查诊断之旅。
当时的代码没有了，为了更好的还原现场，还是跑一个模拟程序。
首先，采用 top 命令，找出 CPU 占用最高的进程 PID；
然后，通过 ps -ef | grep PID 查看对应的应用，确认一下是不是你的应用，运维喵别给扣错帽子，说啥咱也不能背锅。
接着，采用 jstack -l PID >> PID.log 获取进程的堆栈信息。
然 后，采用 ps -mp PID -o THREAD,tid,t ime 拿到占用 CPU 最高的线程 TID。
接着，采用 printf "%x/n" tid 获取 16 进制的线程 TID。
最后，采用 grep TID -A20 PID.log 确定是线程哪儿出了问题。
找到代码位置，便可对症下药。
另外，你或许会感觉命令繁琐，其实摆脱命令的困扰，采用 VisualVM 图形化性能监控工具，则会有种土枪换炮的感觉，不过生产上一般还是用命令的居多（言外之意：势必要掌握命令）。
3.
编程经验从哪儿来？ 作为一个久经职场的码农， 真心 的告诉你，经验来源于填坑 ，遇到的坑越多， 经 验越丰富， 虽然遇到的 问 题可能变幻莫测，但是解决问题却有章可 循 。
用心画了一部 Java 程序优化的「葵花宝典」，丑是丑了点，但是真能解决大问题，请放心收藏。
好了，今天的分享接近尾声， 以备不时之需， 建议你好好收藏，最重要的是去拿去实践 。
推荐阅读：
Java 程序该怎么优化？技巧篇
Java 程序该怎么优化？命令篇
Java 程序该怎么优化？工具篇
正文到此结束
热门推荐
相关文章
Loading...
![[HBLOG]公众号](https://www.harries.blog/img/qrcode_gzh.jpg)
