线上问题总结（持续更新中）

排查思路

Java线上问题的排查思路可以分为以下几个步骤：

1、确定问题现象：首先需要明确问题所表现的具体情况，包括错误信息、日志记录等。这有助于我们更好地理解问题并进行后续操作。
2、收集相关数据：在发生问题时，及时收集与该问题相关的数据，如服务器状态、应用程序运行参数、系统配置等。这些数据将对后续的故障排除非常重要。
3、复现问题：根据已知的问题现象，尽量模拟或者再次触发同样的问题。通过多次测试来获取更多的信息，从而能够更加全面地了解问题的原因。
4、调试工具使用：利用Java开发中提供的调试工具（如IDE自带的调试功能）来定位问题所在。设置断点、单步调试等手段，逐步追踪代码执行流程，找到导致问题的具体代码片段。
5、日志分析：结合应用程序的日志文件，分析其中的错误信息、异常堆栈等内容，以此判断问题的根本原因。特别注意查看异常类型、错误消息等关键字段。
6、性能分析：当问题无法通过日志分析得到解决时，可以使用性能分析工具（如JProfiler、VisualVM等）来深入分析应用程序的性能指标，比如CPU使用率、内存占用等，以找出潜在的性能瓶颈。

问题一

现象：

登陆之后，频繁登陆不上，服务正常启动，注册中心nacos上的服务上线之后又下线，访问接口，接口日志报nullPointException（A服务调B服务的业务方法报错，B服务就是频繁下线的服务）。

排查思路：

1、登录后又自动下线

检查nacos上的服务，是否正常注册，结果发现，注册后就下线了，重启服务还是如此

2、访问接口，接口日志报nullPointException

由于刚好是下线的服务，定位B服务出现问题

3、检查B服务的日志，尤其是相关接口的报错日志，发现接口访问非常慢，报错如图

4、检查sql发现，两表做内连接，没有连接条件，查询量过大（17万条），导致jvm频繁gc，初始化大量数据到jvm内存中，这就导致了内存资源紧张，后台日志不断报内存溢出和GC回收异常的问题，

5、nacos服务注册后，一直下线

服务在jvm的分配的内存使用完毕后，在后台运行的向nacos服务端保持心跳的线程阻塞或者被杀死了，导致后面nacos服务器接收不到来自客户端的心跳，从而服务后面没有再次被nacos服务端发现

6、踩坑总结

刚开始没有看日志，分析可能内存不足，频繁gc导致的，所以就查看了gc日志，发现频繁young gc，大概增加2000次/6s young gc，1次/6s full gc，之后增加年轻代内存空间，启动服务，发现有好转，接口不报错了，频繁点击后又出现报错，原来接口报错只有报错信息（sql和gc overhead），增加年轻代内存后，有数据输出日志，分析查询量过大

7、相关指令总结

top 查看cpu使用情况，服务器内存占用情况
jinfo -flags pid 查询虚拟机运行参数信息。
jinfo -flag name pid 查询具体参数信息，如jinfo -flag UseSerialGC 42324，查看是否启用UseSerialGC
jps 查看本地正在运行的java进程和进程ID（pid）
jmap -heap pid 输出堆内存设置和使用情况（JDK11使用jhsdb jmap --heap --pid pid）
ps -ef|grep 服务名 查询服务对应的pid
java -Xms256m -Xmx512m -Xss512k
ps -aux|grep -v grep|grep 进程pid 查看进程pid对应的服务

设置JVM内存的参数有四个：

-Xmx Java Heap最大值，默认值为物理内存的1/4，最佳设值应该视物理内存大小及计算机内其他内存开销而定；

-Xms Java Heap初始值，Server端JVM最好将-Xms和-Xmx设为相同值，开发测试机JVM可以保留默认值；

-Xmn Java Heap Young区大小，不熟悉最好保留默认值；

-Xss 每个线程的Stack大小，不熟悉最好保留默认值；

问题二

现象：

上传文件的接口，出现两种情况，文件破损和文件缺失
排查思路：

1、分析代码本身是否有bug

文件缺失：通过分析把缺失的校验加上后，生产还会出现问题
文件破损：代码层面没有问题

2、接口性能分析

通过日志数据发现，当接口出现并发情况下时，很可能出现此问题

3、解决问题

加防止表单重复提交的代码逻辑，或者加分布式锁控制，这两种本质都是分布式锁防止并发产生脏数据（解决方式之前写过相关文章介绍）

问题三

现象：接口用时太长

可以从以下几点进行分析和解决

1、sql写的复杂，未使用索引，查询时间长
2、分析接口是否是串行，若为并行，则可以使用异步线程CompletableFuture进行优化，或者消息队列