经常会被问你解决过线上问题没，怎么解决的，下面谈谈我遇到过的线上问题已经解决思路，但是肯定不全
1.CPU过高的问题
这个问题非常常见，但是这个问题的出现，大概率是因为程序代码的问题，导致有死循环而且死循环没有sleep，还有使用第三方工具由于使用的不合理或者工具存在的隐藏bug也会产生死循环的问题，该问题的排查思路一般是top找到cpu占用最大的进程，然后根据这个进程pid找到进程中占比cpu最大的线程，找到线程后，使用jvm工具jstack打印出当前线程的堆栈，比对找到对应的线程，然后排查原因，也可以使用工具Arthas等去排查，可能更简单。
代码1
我们使用redis消费队列时，如果获取不到数据时，需要sleep个时间再返回（死循环逻辑同理），如果不sleep而且长时间获取不到数据，就相当于整个cpu在空转，很快cpu就100%了，这里解决方案除了sleep，还可以使用redis本身提供的阻塞队列的方式，让redis去处理，但是要处理异常的情况，可能需要捕获异常处理
还有一次我们使用的一个第三方的做数据库sql解析的工具，当如果配置的sql满足某一个条件时，会导致抽象语法树解析出现问题，造成了死循环，线上cpu出现100%，我们换成另一个公式就完全没问题，这种就是第三方的问题，代码非常复杂，我们向源码作者提出了，但是修复是一个漫长的逻辑，我们只好换成了另一个Druid框架，解决这个问题。
2.内存过高的问题
出现该问题，先排除流量攻击，流量过大问题，基本可以从几个方面着手：
内存泄漏：是否有静态变量活着常量list或者map等一直在加数据，又没有定时清理，导致数据越来越大，最终导致oom了，解决这个问题先从业务出手，是否可以清理，怎么清理，避免内存泄漏；
大对象：这个是主要产生的原因，大对象产生有可能是代码的逻辑有问题导致，也有可能是数据库没分页或者查询的时候没有条件（例如mybatis使用if的时候条件没传入，会查询所有）导致一次性会读取大量的数据，导致内存的瞬间爆炸，导致oom
MetaSpace不足：一般是因为程序代码越来越多，jvm设置的参数还是以前的值，而且代码中存在的动态代理或者反射比较多，可能会导致
解决思路：限流 定时清理 分页 jvm参数调优
3.数据库死锁
产生的原因是相互等待，例如A事务在等B事务的锁，而B事务在等A事务释放锁，导致他们都释放不了，出现了循环等待，产生死锁
一般在做批量删除或者更新操作时会产生此问题，如果是使用mysql，隔离级别是RR时，该问题出现的可能性更高，因为此时区间锁会生效，锁的范围更大，因为批量更新操作在数据库层面是一个个更新的，例如A事务需要更新记录1和2，B事务需要更新2和1，A事务在更新1后,B事务正好在更新2，然后A事务在更新2的过程中，需要等待2记录的锁释放，而B事务需要等待记录1的锁释放，出现了循环等待,产生死锁
解决方案：
1.减小事务的粒度，事务只做更新操作，其他逻辑不要放在事务中
2.批量操作是否可以改为单个操作，或者保证批量更新的顺序是一致的，这样就不会出现死锁
3.减小事务的隔离层级，因为RR是锁区间，出现死锁的可能性更大，是否在业务需求范围内，改为RC减小这种死锁发生的概率
4.接口查询时间慢
找到查询慢的接口，定位出慢的原因，一般会有几个方面的原因：
1.逻辑混乱，效率低，例如循环里面查询数据库，接口嵌套层级太深，导致很多重复查询的数据，可以使用ThreadLocal，ddd等解决
2.慢SQL：索引失效，索引设置不合理，或者根据条件查询出的数据还是很大这种
3.数据一次性查询量太大
4.流量太大，导致线程在等待队列中
5.fullgc频繁
解决方案：限流熔断 合理建索引 sql优化 加缓存 分页查询 jvm调优 异步化
异步化：很多的逻辑用户可能不需要同步查看或者提供给用户进度查看，例如导入导出这种
网友评论