java突发内存和CPU同时100%排查解决

轻量应用服务器部署Springboot项目+后台持续运行 Springboot项目部署到腾讯云服务器,详细图文记录下自己完整部署过程,能够成功运行,其他云服务器部署方式相似 阅读详情

问题说明

springBoot 微服务项目,生产环境突然CPU和内存使用率都100%,导致接口请求超时。

初步排查

  1. 接口慢首先排除数据库和慢sql的影响,本次问题是所有接口同事慢,不是单个接口,所以不是数据库问题。
  2. 大面积接口慢很可能是CPU负载高,生产环境都有服务器监控,查看监控。
    在这里插入图片描述
    在这里插入图片描述
  3. 如果CPU很高,内存正常,很可能是那一段程序消耗cpu。首先使用阿里的arthas工具,thread -n命令查看cpu高的堆栈,然后再解决。
    我们遇到的是内存也很高,很可能是垃圾回收占用CPU,先用命令行快速排查一遍。
    jstat查看堆内存使用情况:jstat -gcutil 1 1000
    1000ms输出一次,线程pid=1的内存使用情况
    在这里插入图片描述
    jmap查看存活对象:jmap -histo:live 1
    统计pid=1的程序,存活对象使用情况,发现两百多万个业务对象。
    在这里插入图片描述
    总结:以上排查都是现有监控和简单命令行,进入服务器就可以快速得到结论。由于业务对象有几十个地方都用到了,不确定那个方法引起的,所以需要进一步深度排查,dump内存进行分析

使用MAT工具分析dump内存

  1. 保留事故现场,dump内存
    jmap -dump:format=b,file=/test/jmap_dump_all.hprof
    我们服务器内存比较大,dump文件7G,先zip压缩再下载到本地进行分析。zip压缩后大小1G。

  2. 安装和调试mat工具

  • 我用的mac,下载mac最新版本 : https://www.eclipse.org/mat/previousReleases.php
    在这里插入图片描述
  • 由于国内主流是java8,mat工具打开会报错,最新版本需要java11启动。
    在这里插入图片描述
    下载解压jdk11(不用配置环境变量) 进入Oracle 官网:https://www.oracle.com/java/technologies/downloads/#java11
  • 配置jdk
    step1. 在应用列表,找到mat应用,然后右键单击后,选择“显示包内容”
    step2. 进入Contents目录,找到Info.plist文件
    step3. 打开Info.plist文件
    step4. 编辑-vm配置,将解压的jdk11目录配置上
    在这里插入图片描述
    在这里插入图片描述
  • 默认只能打开1024M的文件,7G文档打开会报错OOM
    在这里插入图片描述
    在这里插入图片描述
  1. 使用mat工具
  • 用mat工具打开dump文件
  • 点击dominator_tree
  • 查看内存占用高的详情,根据堆栈找到入口接口
    在这里插入图片描述
    在这里插入图片描述

最后

mat工具找到占用内存的入口堆栈和具体对象,最后就是根据业务去优化了

面试题:Java程序CPU 100%问题排查指南 当Java程序出现CPU使用率达到100%的情况时,通常意味着程序存在性能瓶颈或无限循环等问题。以下是系统化的排查方法和解决方案: 阅读详情

相关推荐

线上服务CPU 100%报警,排查发现是Java的C2编译器在‘死循环’,我是这样定位和解决的

本文详细分析了线上服务CPU 100%报警的排查过程,发现是Java的C2编译器线程陷入死循环。通过定位高CPU线程、分析JIT编译原理和深入诊断,最终确定问题根因并提供了临时和长期解决方案,包括禁用C2编译器或升级JDK版本。文章还分享了构建防御性监控体系的实践经验,帮助开发者预防类似问题。

weixin_33672400的博客 262

springboot应用,cpu高、内存高问题排查

回顾一下整个排查过程,有几个点说一下1)、写方法一定要注意动态的情况,比如此例中,数据后期增长的情况,不能只考虑当时的数据。2)、有个疑问,就算对象不可达了,正常来说也可以从MAT里看到点相关东西才对,但是翻了很久,啥也没看到,MAT的使用还要再看看,感觉是遗漏了细节3)、还有个疑问,虽然对象确实很大,但是可以回收,那rancher上看到的内存为啥还会这么高呢?这也是一个疑问点,需要找时间了解一下rancher。

qq_39839075的博客 6800

玩转MySQL:定位排查解决突发Bug

线上排查、性能优化等内容是面试过程中的“常客”,而对于线上遇到的“疑难杂症”,需要通过理性的思维去分析问题、排查问题、定位问题,最后再着手解决问题,同时,如果解决掉所遇到的问题或瓶颈后,也可以在能力范围之内尝试最优解以及适当考虑拓展性。 对于线上排查方面的文章,在之前的《JVM专栏》中,也出过一篇关于《JVM线上故障排查》的文章,性能优化也好,线上排查也罢,其实无论在哪个技术栈中,做这些工作的核心思想亦是共通的,所以MySQL线上排查的步骤,同样可参考JVM的线上排查步骤。

Java_LingFeng的博客 1166

springboot运行一段时间cpu过高

3. 找出最高占用的线程并记录thread_id, 把线程号换算成16进制编号:printf "%X\n"【thread_id】4. 查看高负载线程并找到具体方法: jstack 【进程】|grep 【线程】 -a 100(打印100行)5. 也可以导出进程的堆栈日志:jstack 【线程号】 > /home/test.log。2. 查看高负载进程下的高负载线程:top -Hp 【pid】1. top命令找出最高占用的进程ID。可使用jdk自带的工具jstack。

wangyf1129的博客 1244

MySQL排查篇:该如何定位并解决线上突发的Bug与疑难杂症?

其实排查这类问题不难,主要是得先定位到对应的线程,然后再找出OS线程对应的MySQL线程,找到对应的MySQL线程后,再找到其正在执行的SQL语句,因为线程是执行这条语句才导致占用高额CPU资源的,因此最后只需要把SQL的逻辑调整合理后,就能够彻底解决CPU占用过高的问题。为啥不写如何解决内存相关的问题呢?

Java_zhujia的博客 1082

Java内存使用异常导致CPU100%原因(线上JVM排查之二)

写这篇博客的初衷是发现线上JVM问题以及排查,觉得有必要记录并分享出来,有感于很多市面上的教程讲述JVM的教程,甚至还有很多深入到Java字节码和JVM底层源码领域等深入知识,我不否认这些理论和源码也很重要,但是很多学生学习的云里雾里,等学完这些遇到线上问题还是不会排查,实际解决工作中的问题才可以真正做到技术的融会贯通,才可以深入去学习和理解Java字节码和JVM底层源码。

深度Java 2088

java 应用cpu飙升(超过100%)故障排查

记一次生产环境java应用cpu飙升(超过100%)故障排查记录

qq_33129875的博客 1万+

线上Java应用CPU占用率100%的故障排查与分析

通过使用jstack等工具获取线程栈信息,并分析定位导致CPU占用率高的线程,可以帮助我们快速排查和修复问题。最终,通过优化代码、异步处理和调整线程池配置等手段,可以降低CPU占用率,提高应用的性能和稳定性。获取线程栈信息:使用JDK提供的工具jstack,可以获取Java进程中所有线程的栈信息。通过分析线程栈,我们可以了解每个线程正在执行的代码,从而找到可能导致CPU占用率高的线程。确认CPU占用率:首先,我们需要确认应用程序的CPU占用率是否真的达到了100%,可以通过命令行工具或监控系统获取。

CyberByte的博客 568

CPU使用率100%的故障排查记录

注:这些数据在内存里持续了很长时间,SQL执行时间是在14:27分,但到合作方的运维同事抓jstack堆栈的14:47分时,线程仍然处于Runnable状态,说明这些数据已经在内存里常驻了至少20分钟以上。

golfxiao的专栏 1845

Java内存异常触发FGC无效导致CPU持续100%原因(线上JVM排查之三)

提高Java性能需要避免FGC,本文就是以一则线上真实的案例来分析FGC导致CPU100%,以及这个中间年轻代,年老代的变化。

深度Java 1576

MicroLogix1400编程(使用RSLogix 500 + RSLinx Classic Lite)

MicroLogix1400编程

noscallion的博客 1万+

【进阶-排查】CPU 飙高/100% 原因和排查

CPU使用率飙升原因和排查

金哥的博客 502

基于Python的微信聊天记录分析——数据获取

本篇为“基于Python的微信聊天记录分析”第一篇,主要涉及数据获取,包括Python环境配置、WeChatMsg项目配置和运行、获取聊天记录等内容,流程简单、比较基础,后续这个系列会涉及基于Python的数据处理、统计分析、NLP技术等内容。希望和大家多多交流,共同进步!

Henryli1202的博客 1万+

服务出现OOM,cpu飙升至100%原因调查及解决方法

服务出现OOM,cpu飙升至100%原因调查及解决方法

hgq0916的博客 5115

model_optimizer将pi05端到端延时进一步优化到68.13ms了

目前在保持灵活性和性能之间找到一个较好的平衡。vit, llm仍然使用onnx->trt_engine的路径,量化可以通过https://github.com/NVIDIA/Model-Optimizer.git支持。同时支持通过cutedsl手写算子进行进一步优化denoise因为步数多,kernel launch多,因此完全通过手写融合算子实现,将所有steps进行一次大的cuda graph capture.

happyAnger6的专栏 59

从登录到应用可见:在 SAP S/4HANA Cloud Private Edition 中创建用户与打通 SAP Fiori 权限的完整思路

在SAP S/4HANA系统中,用户创建远非简单的账号开通,而是涉及认证、授权、数据访问等多维度的复杂过程。用户主数据记录(User Master Record)是系统访问的起点,包含登录方式、角色分配等关键信息。认证解决"你是谁"的问题,授权则决定"你能做什么"。SAP Fiori访问链路涉及Launchpad内容分配、应用启动映射、OData服务权限等多层校验。角色(Role)通过PFCG维护,包含业务目录(Catalog)和空间(Space)等元素,共同构成完整

2007 年 ~ 2025 年,深耕 SAP 技术 18 年 149

java要cpu_线上CPU飙升100%问题排查,一篇足矣

一、引子对于互联网公司,线上CPU飙升的问题很常见(例如某个活动开始,流量突然飙升时),按照本文的步骤排查,基本1分钟即可搞定!特此整理排查方法一篇,供大家参考讨论提高。二、问题复现线上系统突然运行缓慢,CPU飙升,甚至到100%,以及Full GC次数过多,接着就是各种报警:例如接口超时报警等。此时急需快速线上排查问题。三、问题排查不管什么问题,既然是CPU飙升,肯定是查一下耗CPU的线程,然后...

weixin_39922749的博客 280

【GRASS GIS零基础入门教程】2.1:初识GRASS GIS软件

GRASS GIS是一个强大的计算引擎,用于栅格、矢量和地理空间处理。它支持地形和生态系统建模、水文、数据管理和图像处理。通过内置的时态框架和Python API,它可以进行高级时间序列分析和快速地理空间编程,并针对各种硬件配置的大规模分析进行优化。

智慧空间实验室 847

MySQL - 查询卡顿排查:从 CPU、内存到 IO 的全面分析

MySQL查询卡顿排查指南 本文系统化分析MySQL性能瓶颈,从CPU、内存、IO三大维度定位问题: 现象分类 突发性卡顿:检查慢查询日志和EXPLAIN分析 持续性高负载:监控进程列表和资源使用 周期性卡顿:排查定时任务影响 关键排查方法 CPU瓶颈:通过索引优化减少全表扫描,避免复杂排序和低效JOIN 内存瓶颈:调整Buffer Pool大小,优化表结构减少内存占用 IO瓶颈:监控磁盘利用率,优化redo log配置和硬件升级 实战建议 避免SELECT *,分离大字段数据 建立覆盖索引提升查询效率 定

千淘万漉虽辛苦,吹尽狂沙始到金 2万+

合肥工业大学操作系统实验8

依据操作系统课程所介绍的地址映射与内存共享的原理,本实验的目的是深入理解物理内存的分页管理方式。 深入理解操作系统的段、页式内存管理。包括理解段表、二级页表,以及逻辑地址、线性地址、 物理地址的映射过程。编程实现段、页式内存管理上的内存共享,从而深入理解操作系统的内存管理。从而加深对教材上地址映射与内存共享的理解。

Martin-share的博客 1721

在SAP系统中,公司间关联交易(Intercompany Transactions)或内部往来主要有三种经典的实现模式。这些模式的选择取决于企业的业务复杂度、自动化需求以及对实时性的要求

SAP系统中公司间关联交易的三种实现模式分析:1)手工记账模式(FB60/FB70)适用于低频交易,灵活性高但易出错;2)SD/MM跨公司销售采购模式(VA01/VF01/ME21N)适用于真实业务流转,业务财务集成度高;3)自动清算模式(F.13/ICR)适合高频交易集团企业,支持实时自动对账。关键成功要素包括正确配置贸易伙伴字段、统驭科目及专用凭证类型。建议根据企业规模、业务复杂度及自动化需求选择合适模式,其中大型集团优先考虑自动对账方案以确保合并报表准确性。

金牌架构师 553

【故障复盘】线上突发 OOM 与 CPU 100%:基于 MAT 的 Java 内存泄漏深度排查全记录

一、故障现场与现象定位周三下午核心计费集群突发报警,服务节点呈现典型的级联失效:监控指标突变:节点 JVM 老年代(Old Gen)占用率突破 98%,频繁触发 Full GC。CPU 飙升 100%:垃圾回收器(G1 GC)进入并发循环停顿(Concurrent Mode Failure),GC 线程疯狂抢占 CPU 时间片。

xulihua2的博客 6

避坑指南:新手爬百度图片3个致命错,改完批量保存本地(亲测有效)

新手爬百度图片的核心是“绕开静态HTML,抓准API接口+处理反爬+提取原图”,改完本文提到的3个核心错,就能稳定批量保存高清图片。这套思路可复用在其他图片网站(如必应图片、360图片),只需修改API接口和参数即可。如果想进一步优化,可添加代理IP池、多线程下载(新手不建议,容易触发反爬)、图片去重等功能!

专注于Python爬虫开发,分享爬虫技巧、项目实战与反爬经验,使用Scrapy、BeautifulSoup等工具,解决数据抓取难题。 1586

运维面试八股--大厂面试必问,CPU 100%了你该怎么办

生产环境下下cpu 100%是一个常见问题,原因有非常多,作为运维当秉承着保障在线业务稳定性第一的原则,优先解决问题,而后协同研发排查。至于cpu 100%的原因,常见的业务代码问题,网络突发,服务器容量不足,连接数超限,内存不足等等,生产环境下导致最终cpu 100%的原因还有很多,还需要各位同学在生产环境中多积累和总结。运维相关岗位面试时涉及到知识面非常广,所以复习起来会有无从下手的感觉。为了让同学们面试不迷茫,都能找到一份好工作,我们整理了运维面试的高频面试题,关注我们回复“面试题”免费领取。

wangzizhizu的博客 2641

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

数学建模模型总结

这是本人在两年内准备参加数学建模竞赛搜集到的模型资料,已经经过了本人的筛选和整理,希望能够对准备参加数学建模竞赛的学弟学妹们提供一些帮助!

线上突发 CPU 飙高:快速定位与解决指南

CPU 飙高指系统 CPU 使用率持续接近或达到 100%,通常伴随响应延迟或服务不可用。用户时间(%user):应用代码执行耗时。系统时间(%sys):内核操作(如 IO、网络)耗时。等待时间(%iowait):IO 等待。空闲时间(%idle):CPU 未使用。通过top、jstack、Arthas 和监控系统,可快速定位线上 CPU 飙高。示例模拟死循环,使用 jstack 和 Arthas 定位问题,优化后 CPU 恢复正常。配置 JVM GC 日志和 Actuator 监控。

lssffy的博客 1466

蓝牙模块HM-10手册

蓝牙模块HM-10手册,该手册对蓝牙模块HM-10进行了详细的介绍和使用方法以及一些AT指令。

Java应用CPU 100%排查:从jstack到系统化治理

CPU使用率是衡量系统性能的核心指标之一,其异常飙升往往意味着应用存在性能瓶颈。从技术原理上看,CPU高负载通常由用户态计算密集型任务或系统态频繁的系统调用、上下文切换导致。在Java应用场景中,这直接关系到应用的响应能力和稳定性。通过工具链(如top、jstack、Arthas)进行分层定位,可以快速区分是死循环、锁竞争还是GC问题。这种系统化的排查方法不仅能解决即时故障,更能为构建长效监控体系(如集成APM工具、建立应急预案)提供基础,最终实现从被动救火到主动预防的转变,提升线上系统的可观测性与鲁棒性。

weixin_30252709的博客 412

大中型超市收银系统(可直接运行)

光步前台收银系统系统功能:商品销售、商品退货、挂单、收银员权限、会员销售、单品取消、整单取消、商品查询、脱机销售、脱机数据上传,基本资料下载,开钱箱、小票打印、收款结算,支持多币种付款方式(现金、储值卡、礼券、微信等),支持多种促销。运行环境:.net 4.0登陆信息用户名:1001 密码:123456内置商品信息,商品编码可输入00001000 - 00010000,测试效果相关功能键F5 结算 F9挂单 F11商品查询 F8退货 Insert单品取消 Del整单取消 F12开钱箱F2 会员 Ctrl+Z退出系统 Home 锁屏 相关源码待公开

上一篇: k8s nginx ingress原理解读
鲫鱼哥
博客等级 码龄10年 18粉丝 36原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值