JavaWeb在线问题.分析实例

日常解决线上问题：

1. 首先会根据问题做简单的判断，然后再看问题在哪，然后具体排查
2. 判断依据是功能，考虑一下这个实现这个功能依赖的组件。
3. 一般问题分析步骤：
   1. 首先判断是报错，还是功能失效
   2. 然后根据功能判断下，可能存在的问题。这类问题如果存在也会对哪些功能有影响
   3. 比对下类似功能，看是否是一个类问题。如果是一类问题，那么分析这些功能之间的共同点，其实在你选择类似功能验证的时候已经有一个预判
   4. 如果只是个例，就具体分析。首先捋一下逻辑，分段检测，并逐步缩小问题范围
   5. BS架构首先看http报文，判断是前端还是后端问题
   6. 判断DB是否可访问，中间件是否可以访问
   7. 根据service接口方法在链路系统中查看是否有报错，或者查看后端的日志是否有报错。如可以还原问题现场(原来有类似的系统支撑，或用测试账号测试一下)查看日志或者调用链路，一般情况既然功能有问题，都有点蛛丝马迹
   8. 如果系统不反应，没有日志，请求也超时。那么就需要分析是否系统超负荷负载
   9. 如果是分布式微服务架构风格，微服务多的情况下，一般都有监控报警系统，查看邮件或者短信是否收到报警信息，如果么有类似系统，只能去服务器一台一台机器查看了。当然如果你的服务比较小，就几台机器，一台一台查看也比较快。
   10. 对单台服务器无非是CPU不够用，内存不够，磁盘满了，线程阻塞(死锁),当然也需要判断网络是否通着。这些都是操作层面的东西，只有定位到这几类中才可以继续往下核查
   11. CPU，内存，线程死锁 一般表现问题功能慢，超时
   12. 磁盘满了，会影响日志的打印，上传文件，表现出来的是报错，而不是超时
   13. 网络问题则更为直接，请求过不去，直接失败
   14. 具体技术下面在进行分类和介绍，线上问题首先是解决保证可运行，然后才是考虑优化，包括不限于硬件升级，架构调整，JVM调优，维护策略等
4. 比如业务说上传文件有问题
   1. 首先确定是报错，还是慢
   2. BS架构的话看看是接口报错，http报文，判断是否报错，判断前端还是后端问题
   3. 比对其他类似功能是否OK，如有问题大概率是共同依赖的FS(文件系统)出了问题，或者服务器磁盘满了，无法生成中间临时文件等
   4. 如果是慢，测试下本地网络看看是不是慢；如果可以重现，根据日志看看慢在哪
   5. 如果服务器操作明显感觉卡顿，就有必要看看当前机器cpu，内存，磁盘
   6. 如果都没问题，看看日志是否打印和在某个地方卡顿
   7. 如果日志没用打印就需要进行线程分析
   8. 线程被阻塞，先根据功能分析卡顿在何处，卡顿一般都是需要等待阻塞而不是平白无故停在某个地方，如果代码分析不清楚就需要进行线程分析了
   9. 首先判断javaweb服务进程是否cpu，内存占比高，还是被其他进程影响
   10. 如果是自己问题，就需要打印线程栈，分析线程的阻塞情况；同时也需要注意是否GC导致的问题，如果是GC问题顶多是很慢，不是一直卡顿；如果资源禁止导致阻塞等待，就需要分析是否这个资源需要扩容