持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第7天，点击查看活动详情
背景
测试发现服务无法访问，经过排查发现服务已经启动了，无法访问原因是由于服务没有在nocas上面注册，经过重启后服务可以注册成功，但是运行一段时间后，服务又在nocas上掉线了，于是对问题进行了排查
排查过程
由于nocas又心跳检测机制，如果超过30s不连接会存在掉线的情况，经过分析后，考虑一种可能，就是当服务的GC时间过长，那么服务卡顿，会存在此问题，于是使用Arthas来进行服务监控
Arthas
Arthas 是Alibaba开源的Java诊断工具。安装在系统所在服务器。可以帮助开发人员或者运维人员查找问题，分析性能，bug追踪。
下载: wget alibaba.github.io/arthas/arth…
启动: java -jar arthas-boot.jar
- 输入dashboard，回车，仪表盘显示当前进程相关信息。
- 查看具体线程信息使用 [thread 线程id]
- ps -ef|grep java
可以看到java指定的服务pid
找到我们服务的pid，也可以通过jps -l命令或得pid 这里面有一个坑，就是我在最初用另一账号时可以通过ps -ef|grep java命令获取到java的pid，但是通过jps却什么也获取不到，和运维沟通后发现是账号权限问题。
下面我们进入arthas中。
java -jar arthas-boot.jar 20101
我们看下arthas监控的面板
可以看到线程信息，堆内存，非对内存。
- head 堆内存使用情况 XMS XMX
- ps_eden_space 是年轻代edgn区
- ps_survivor_space 是年轻代的survivor去 网上说edgn区和survivor区是8:1:1 但是显然我们这不是
- ps_old_gen 老年代区
- mataspace 元空间区
- direct 为直接内存区
- gc.ps_scavenge.count young gc次数
- gc.ps_marksweep.count full gc次数
可以通过arthas对nocas心跳检测方法进行监控
从这里来看并没有看到问题，考虑到分配内存并不多，于是调用大数据量查询接口，现象出现了，通过top发现cpu占用100%，且arthas无法进入服务，经过分析，30s后nocs服务注册显示掉线，40s后服务又的内存又恢复正常。
经过分析，原因是由于大数据量占用大量内存，内存空间不足产生full gc，full gc时，垃圾回收器会进行线程调用来回收对象，导致cpu飙高，从而服务卡顿，无法维持心跳连接，nocas掉线。
其实这里还隐藏一个坑，就是nocas如果时临时实例如果掉线后，就算程序恢复正常，nocas也不会让程序注册到nocas注册中心，只有配置成费临时实例才能恢复，且临时实例时nocas默认的实例状态，的确有些与众不同。
后记
有些时候了解一些原理的确可以增加一些解决问题的思路，多和同事探讨一些技术上的难题也能帮助打开自己思路，技术也是众人拾柴火焰高，如果能够更好的对技术进行交流和探讨，对技术的成长非常有助益，闭门造车算是技术成长上的拦路石，多听，多看，多想，一定有所斩获
