全国免费电话:400-888-8888

2021欧洲杯竞猜app行业资讯

让bug无所遁形!你真的会Java 线上问题排查思路,使用好常用工具?

本文摘要:本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知,省得在遇到实际问题时手忙脚乱。只不外这里先提示一下。在线上应急历程中要记着,只有一个总体目的:尽快恢复服务,消除影响。 不管处于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题纷歧定能够定位问题,也纷歧定有完美的解决方案,也许是通过履历判断,也许是预设开关等,但都可能让我们到达快速恢复的目的,然后保留部门现场,再去定位问题、解决问题和复盘。

2021欧洲杯竞猜app

本文总结了一些常见的线上应急现象和对应排查步骤和工具。分享的主要目的是想让对线上问题接触少的同学有个预先认知,省得在遇到实际问题时手忙脚乱。只不外这里先提示一下。在线上应急历程中要记着,只有一个总体目的:尽快恢复服务,消除影响。

不管处于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题纷歧定能够定位问题,也纷歧定有完美的解决方案,也许是通过履历判断,也许是预设开关等,但都可能让我们到达快速恢复的目的,然后保留部门现场,再去定位问题、解决问题和复盘。在大多数情况下,我们都是先优先恢复服务,保留下其时的异常信息(内存dump、线程dump、gc log等等,在紧迫情况下甚至可以不用保留,等到事后去复现),等到服务正常,再去复盘问题。好,现在让我们进入正题吧。

常见现象:CPU 使用率高/飙升场景预设:监控系统突然告警,提示服务器负载异常。预先说明:CPU飙升只是一种现象,其中详细的问题可能有许多种,这里只是借这个现象切入。注:CPU使用率是权衡系统忙碌水平的重要指标。

可是CPU使用率的宁静阈值是相对的,取决于你的系统的IO麋集型还是盘算麋集型。一般盘算麋集型应用CPU使用率偏高load偏低,IO麋集型相反。常见原因:频繁 gc死循环、线程阻塞、io wait...etc模拟这里为了演示,用一个最简朴的死循环来模拟CPU飙升的场景,下面是模拟代码,在一个最简朴的SpringBoot Web 项目中增加CpuReaper这个类,<pre data-tool="mdnice编辑器" style="margin: 10px 0px; padding: 0px; max-width: 100%; box-sizing: border-box !important; word-wrap: break-word !important; border-radius: 5px; box-shadow: rgba(0, 0, 0, 0.55) 0px 2px 10px;">`/**/* 模拟 cpu 飙升场景 * @author Richard_yyf */@Componentpublic class CpuReaper { @PostConstruct public void cpuReaper() { int num = 0; long start = System.currentTimeMillis() / 1000; while (true) { num = num + 1; if (num == Integer.MAX_VALUE) { System.out.println("reset"); num = 0; } if ((System.currentTimeMillis() / 1000) - start > 1000) { return; } } }}打包成jar之后,在服务器上运行。

java -jar cpu-reaper.jar &第一步:定位出问题的线程方法 a: 传统的方法top 定位CPU 最高的历程执行top下令,检察所有历程占系统CPU的排序,定位是哪个历程搞的鬼。在本例中就是咱们的java历程。PID那一列就是历程号。

(对指示符寄义不清楚的见【附录】)top -Hp pid 定位使用 CPU 最高的线程printf '0x%x' tid 线程 id 转化 16 进制>printf '0x%x' 12817> 0x3211` jstack pid | grep tid` 找到线程客栈> jstack 12816 | grep 0x3211 -A 30方法 b: [show-busy-java-threads]这个剧本来自于github上一个开源项目,项目提供了许多有用的剧本,show-busy-java-threads就是其中的一个。使用这个剧本,可以直接简化方法A中的繁琐步骤。如下,> wget --no-check-certificate https://raw.github.com/oldratlee/useful-scripts/release-2.x/bin/show-busy-java-threads> chmod +x show-busy-java-threads> ./show-busy-java-threads` </pre>>`show-busy-java-threads# 从所有运行的Java历程中找出最消耗CPU的线程(缺省5个),打印出其线程栈# 缺省会自动从所有的Java历程中找出最消耗CPU的线程,这样用更利便# 固然你可以手动指定要分析的Java历程Id,以保证只会显示你体贴的谁人Java历程的信息show-busy-java-threads -p <指定的Java历程Id>show-busy-java-threads -c <要显示的线程栈数>方法 c: arthas thread阿里开源的arthas现在已经险些包揽了我们线上排盘问题的事情,提供了一个很完整的工具集。

在这个场景中,也只需要一个thread -n下令即可。> curl -O https://arthas.gitee.io/arthas-boot.jar # 下载`要注意的是,arthas的cpu占比,和前面两种cpu占比统计方式差别。

前面两种针对的是Java历程启动开始到现在的cpu占比情况,arthas这种是一段采样距离内,当前JVM里各个线程所占用的cpu时间占总cpu时间的百分比。详细见官网:https://alibaba.github.io/arthas/thread.html后续通过第一步,找出有问题的代码之后,视察到线程栈之后。我们就要凭据详细问题来详细分析。

这里举几个例子。情况一:发现使用CPU最高的都是GC 线程。GC task thread#0 (ParallelGC)" os_prio=0 tid=0x00007fd99001f800 nid=0x779 runnableGC task thread#1 (ParallelGC)" os_prio=0 tid=0x00007fd990021800 nid=0x77a runnable GC task thread#2 (ParallelGC)" os_prio=0 tid=0x00007fd990023000 nid=0x77b runnable GC task thread#3 (ParallelGC)" os_prio=0 tid=0x00007fd990025000 nid=0x77c runnablgc 排查的内容较多,所以我决议在后面单独列一节讲述。情况二:发现使用CPU最高的是业务线程io wait好比此例中,就是因为磁盘空间不够导致的io阻塞等候内核态锁,如 synchronizedjstack -l pid | grep BLOCKED 检察阻塞态线程客栈dump 线程栈,分析线程持锁情况。

arthas提供了thread -b,可以找出当前阻塞其他线程的线程。针对 synchronized 情况常见现象:频繁 GC1. 回首GC流程在相识下面内容之前,请先花点时间回首一下GC的整个流程。接前面的内容,这个情况下,我们自然而然想到去检察gc 的详细情况。

方法a : 检察gc 日志方法b : jstat -gcutil 历程号 统计距离毫秒 统计次数(缺省代表一致统计方法c : 如果所在公司有对应用举行监控的组件固然更利便(好比Prometheus + Grafana)这里对开启 gc log 举行增补说明。一个经常被讨论的问题(惯性思维)是在生产情况中GC日志是否应该开启。因为它所发生的开销通常都很是有限,因此我的谜底是需要开启。但并纷歧定在启动JVM时就必须指定GC日志参数。

HotSpot JVM有一类特此外参数叫做可治理的参数。对于这些参数,可以在运行时修改他们的值。

我们这里所讨论的所有参数以及以“PrintGC”开头的参数都是可治理的参数。这样在任何时候我们都可以开启或是关闭GC日志。好比我们可以使用JDK自带的jinfo工具来设置这些参数,或者是通过JMX客户端挪用HotSpotDiagnostic MXBean的setVMOption方法来设置这些参数。

这里再次大赞arthas❤️,它提供的vmoption下令可以直接检察,更新VM诊断相关的参数。获取到gc日志之后,可以上传到GC easy资助分析,获得可视化的图表分析效果。

2. GC 原因及定位prommotion failed从S区提升的工具在暮年代也放不下导致 FullGC(fgc 接纳无效则抛 OOM)。可能原因:survivor 区太小,工具过早进入暮年代检察 SurvivorRatio 参数大工具分配,没有足够的内存dump 堆,profiler/MAT 分析工具占用情况old 区存在大量工具dump 堆,profiler/MAT 分析工具占用情况你也可以从full GC 的效果来推断问题,正常情况下,一次full GC应该会接纳大量内存,所以 正常的堆内存曲线应该是呈锯齿形。

如果你发现full gc 之后堆内存险些没有下降,那么可以推断: 堆中有大量不能接纳的工具且在不停膨胀,使堆的使用占比凌驾full GC的触发阈值,但又接纳不掉,导致full GC一直执行。换句话来说,可能是内存泄露了。一般来说,GC相关的异常推断都需要涉及到内存分析,使用jmap之类的工具dump出内存快照(或者 Arthas的heapdump)下令,然后使用MAT、JProfiler、JVisualVM等可视化内存分析工具。

至于内存分析之后的步骤,就需要小同伴们凭据详细问题详细分析啦。常见现象:线程池异常场景预设:业务监控突然告警,或者外部反馈提示大量请求执行失败。异常说明:Java 线程池以有界行列的线程池为例,当新任务提交时,如果运行的线程少于 corePoolSize,则建立新线程来处置惩罚请求。

如果正在运行的线程数即是 corePoolSize 时,则新任务被添加到行列中,直到行列满。当行列满了后,会继续开发新线程来处置惩罚任务,但不凌驾 maximumPoolSize。当任务行列满了而且已开发了最大线程数,此时又来了新任务,ThreadPoolExecutor 会拒绝服务。常见问题和原因这种线程池异常,一般可以通过开发检察日志查出原因,有以下几种原因:下游服务 响应时间(RT)过长这种情况有可能是因为下游服务异常导致的,作为消费者我们要设置合适的超时时间和熔断降级机制。

另外针对这种情况,一般都要有对应的监控机制:好比日志监控、metrics监控诉警等,不要等到目的用户感受到异常,从外部反映进来问题才去看日志查。数据库慢 sql 或者数据库死锁检察日志中相关的关键词。

Java 代码死锁jstack –l pid | grep -i –E 'BLOCKED | deadlock'四、常见问题恢复对于上文提到的一些问题,这里总结了一些恢复的方法。五、Arthas这里还是想单独用一节安利一下Arthas这个工具。Arthas 是阿里巴巴开源的Java 诊断工具,基于 Java Agent 方式,使用 Instrumentation 方式修改字节码方式举行 Java 应用诊断。

dashboard :系统实时数据面板, 可检察线程,内存,gc 等信息thread :检察当前线程信息,检察线程的客栈,如检察最忙碌的前 n 线程getstatic:获取静态属性值,如 getstatic className attrName 可用于检察线上开关真实值sc:检察 jvm 已加载类信息,可用于排查 jar 包冲突sm:检察 jvm 已加载类的方法信息jad:反编译 jvm 加载类信息,排查代码逻辑没执行原因logger:检察logger信息,更新logger levelwatch:观察方法执行数据,包罗出参、入参、异常等trace:方法内部挪用时长,并输出每个节点的耗时,用于性能分析tt:用于记载方法,并做回放以上内容节选自Arthas官方文档。另外,Arthas里的 还集成了 ognl 这个轻量级的表达式引擎,通过ognl,你可以用arthas 实现许多的“骚”操作。其他的这里就不多说了,感兴趣的可以去看看arthas的官方文档、github issue。

六、涉及工具再说下一些工具。Arthas(超级推荐❤️❤️)useful-scriptsGC easySmart Java thread dump analyzer - thread dump analysis in secondsPerfMa - Java虚拟机参数/线程dump/内存dump分析Linux 下令Java N 板斧MAT、JProfiler...等可视化内存分析工具结语我知道我这篇文章对于线上异常的归纳并不全面,另有网络(超时、TCP行列溢出...)、堆外内存等许多的异常场景没有涉及。

主要是因为自己接触很少,没有深刻体会研究过,强行写出来免不得会差点意思,更怕的是误了别人。另有想说的就是,Java 应用线上排查实际很是考究一小我私家基础是否扎实、解决问题能力是否过关。好比线程池运行机制、gc分析、Java 内存分析等等,如果基础不扎实,看得更多的是一头雾水。

另外就是,多看看网上一些有实际场景的关于异常排查的履历文章,学习他们解决排盘问题的思路和工具。这样纵然自己暂时遇不到,可是会在脑海内里逐步总结出一套解决类似问题的结构框架,到时候真的遇到了,也就是举一反三的事情而已。

END这里是天天都很困的JAVA喜好者,如果您跟我一样天天睡不饱却依然热爱JAVA!那就关注我吧!才疏学浅请多指教。


本文关键词:2021欧洲杯竞猜app,让,bug,无所,遁形,你,真的,会,Java,线上,问题

本文来源:2021欧洲杯竞猜app-www.start-hr.com

Copyright © 2001-2021 www.start-hr.com. 2021欧洲杯竞猜app科技 版权所有  ICP备53830494号-3  XML地图