面试官：出现了性能问题，该怎么去排查呢？
程序猿：接口响应那么慢，时间都花到哪里去了？
运维喵：为什么你的应用跑着跑着，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,time 拿到占用 CPU 最高的线程 TID。
接着，采用 printf "%x\n" tid 获取 16 进制的线程 TID。
最后，采用 grep TID -A20 PID.log 确定是线程哪儿出了问题。
找到代码位置，便可对症下药。
另外，你或许会感觉命令繁琐，其实摆脱命令的困扰，采用 VisualVM 图形化性能监控工具，则会有种土枪换炮的感觉，不过生产上一般还是用命令的居多（言外之意：势必要掌握命令）。
3. 经验从哪儿来？
作为一个久经职场的码农，真心的告诉你，经验来源于填坑，遇到的坑越多，经验越丰富，虽然遇到的问题可能变幻莫测，但是解决问题却有章可循。
用心画了一部 Java 程序优化的「葵花宝典」，丑是丑了点，但是真能解决大问题，请放心收藏。
好了，今天的分享接近尾声，以备不时之需，建议你好好收藏，最重要的是去拿去实践。
