java线上问题排查:进程假死或者oom killed

linux中引起OOM Killer的原因及排查思路 OOM Killer(Out-Of-Memory Killer)的触发通常是由于Linux系统内存不足时,内核采取的一种极端保护措施 阅读详情

我们在处理线上问题的时候,如果遇到了程序进程突然被kill掉,可以通过下面的命令来查看程序死掉的时间:

#查看oom被kill的进程
grep "Out of memory" /var/log/messages

在这里插入图片描述
或者:

#查看系统日志:
egrep -i -r 'killed process' /var/log

在这里插入图片描述
或者:

dmesg -T| grep java

在这里插入图片描述

从这些日志中我们可以看到程序oom的时间,结合我们程序本身的日志,可以推算是否是自己的程序挂掉了。

一般java程序在部署的时候会在启动的脚本中加入dump信息来帮助我们迅速定位线上的问题。
例如我写个简单的程序:

public class Main {
    public static void main(String[] args) {
        List<byte[]> list = new ArrayList<>();
        for (int i = 0; i < 10000; i++) {
            list.add(new byte[1024000]);
        }
    }
}

只要程序一运行我们很快就会发现OOM异常:

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at com.xqnode.Main.main(Main.java:10)

从这个异常中我们会快速定位到具体的哪一行出了问题。但是在实际生产环境不会出现这么简单的代码,通常程序是在不同的包中相互调用,而且会有多线程的情况,比较难定位到具体的错误发生的代码,所以我们在启动脚本中加入dump信息,然后我们就能找到对应的问题所在了。这里我们制定dump文件输出到D盘下。
启动配置:
在这里插入图片描述
再次运行程序,出现OOM的时候会在D盘下看到这个文件:
在这里插入图片描述
然后我们使用jdk中自带的工具jvisualvm.exe打开dump文件,路径在jdk/bin下。
点击 文件 => 装入,选择后缀名,打开文件
在这里插入图片描述

看到的界面如下:
在这里插入图片描述
我们从上面的红色部分可以清晰的看到我们的程序错误在哪里。

还可以使用jmap对正在进行的程序进行分析:

jmap -dump:live,format=b,file=heap.bin <pid>
你见过java程序自毁(kill)吗?我踩过 在线音乐戳我呀!音乐博客源码上线啦!之前专栏奔向Linux、Docker前几篇讲了Docker的安装部署,操作算是比较简单。你见过java程序自毁(kill)吗?我遇到过。今天,兴致勃勃想登陆在线音乐听听周董的《稻香》,结果,发现请求音乐接口失败(音乐博客是由java服务提供的第三方服务),于是马上进入服务器看下日志,进行了排查之路。接下来将分享如何在服务器排查java服务无缘无故被kill掉的问题,这个问题非常有意思,主要是很难排查,自己被kill掉,一五一十盘出。 阅读详情

相关推荐

服务器卡死排查指南:从土豆服务器到假死与真死的深度分析

服务器负载过高、性能瓶颈与资源耗尽,是运维和开发者在日常工作中最常遇到的棘手问题之一。当SSH连接卡顿、命令无回显时,这不仅是玩家口中“土豆服务器”的玩笑,更意味着系统可能陷入了假死或真死状态。理解CPU满载、内存不足、磁盘IO阻塞、内核日志异常等底层原理,掌握uptime、top、free、iostat、dmesg等基础排查命令,能帮助工程师快速定位故障根源。无论是应对突发流量导致的资源枯竭,还是诊断进程死锁、文件系统错误,一套系统的排查流程都至关重要。本文结合真实案例,剖析服务器无响应的常见原因与应急恢

weixin_30357231的博客 457

dmesg命令查看java程序突然挂掉的原因

背景: JAVA服务线上毫无征兆的直接crash掉,打开日志查看,日志文件毫无相关挂掉的信息,所以当时直接选择了重启,当时的猜测是:服务内存不足导致程序进程直接挂掉? 查找原因 后来学习查找到一个命令dmesg命令,这个命令还是非常强大的。dmesg命令行实用程序用于在Linux和其他类似Unix的操作系统中打印和控制内核环形缓冲区。对于检查内核启动消息和调试与硬件相关的问题很有用。 可以在服务器执行命令: # 按时间格式显示 dmesg -T # 显示跟java 有关的日志 dmesg -T |.

KingdomCoder 3248

用bash脚本预防Linux OOM Killer:内存监控与自动干预实战

Linux系统内存管理是运维与后端开发的核心议题。当物理内存耗尽时,内核的OOM Killer会根据评分机制强制终止进程,但默认选择往往误伤MySQL、Redis等关键服务,导致业务中断。同时,内存过度分配(overcommit)和swap频繁换页会使系统陷入假死状态。针对这一痛点,基于bash脚本的轻量级内存监控方案应运而生:通过定期采集内存使用率、swap占用和进程RSS,分级触发告警、清理缓存或按白名单终止内存大户。该方案适用于服务器、裸机及容器化场景,能在OOM发生前主动干预,显著降低系统卡死风险。

weixin_34130389的博客 957

论 内核 OOM(out of memery) 引发的 程序被 killed

一、 描述  自己的代码 ,在平时环境中跑着没有问题的,但是today 测试在跑压力的时候 发现程序跑个 5min 左右就自己断了,程序没有产生core文件,而是显示的 是 killed ? 二、可能原因 1、 别人也在用这台机器 手动kill掉 了。 2、程序自己被未知 原因 干掉了 三、寻索 1、首先 确认了 原因一不成立,根本没人动过   2、其次 研究原因2

梦想专栏 5032

服务器卡死现场排查全流程:从硬件到应用层定位与预防

服务器性能问题常表现为运行缓慢、服务无响应甚至系统假死,通常出现在高负载场景如数据采集、GPU推理或批量任务中。其根源涉及硬件资源瓶颈、操作系统调度异常、应用锁竞争以及网络链路故障等多个层面。性能监控与故障诊断是保障系统稳定性的关键环节,通过分析负载指标、内存交换、IO等待和进程状态,能够快速缩小问题范围。在实践中,运维人员常借助系统日志、性能分析工具和监控平台,建立从现象到根因的排查路径。本文围绕服务器卡死这一典型性能事故,梳理硬件、系统、应用与网络四个方向的定位方法,并给出可落地的预防策略,帮助读者形成

weixin_34194087的博客 377

服务器卡死?15分钟定位CPU、内存或磁盘IO瓶颈的排查指南

服务器在高负载下突然卡死,往往表现为SSH连不上、任务无响应,这类被戏称为“土豆服务器”的现象背后,并非单一原因所致,而是CPU、内存、磁盘IO等资源瓶颈的综合体现。要高效恢复业务,关键在于先分辨卡死层级,再按顺序采集现场信息。本文从系统负载与进程状态分析切入,介绍如何借助top、vmstat、iostat、dmesg等基础工具,快速定位是CPU打满、内存耗尽、磁盘IO拥塞,还是文件句柄与网络异常。同时给出临时恢复手段与长期预防策略,帮助运维人员、个人开发者及兼职管理者建立一套可落地的故障排查流程,让服务器

weixin_34034670的博客 404

服务器卡死排查指南:从“土豆”到稳定输出的运维实战

服务器负载过高、响应缓慢,甚至SSH都无法连接,是运维中最常见的“卡死”现场。很多人第一时间选择重启,但服务器卡死并非单一故障,而是CPU、内存、磁盘IO或虚拟化资源竞争等多类问题的综合表现。理解负载(Load Average)、OOM、IO等待等核心原理,有助于区分真死与假死,避免误判。掌握系统化排查方法,能够在现场快速采集关键数据,定位根因,并为容量规划与服务治理提供依据。无论是低配物理机、云主机还是虚拟化环境,这套方法论都适用。从基础概念入手,系统拆解服务器卡死的常见场景,并给出日志留存、资源限制、监

weixin_34005042的博客 405

服务器卡死排查全攻略:从土豆服务器到现场应急的实战方法

服务器卡死是运维和现场交付中常见的棘手问题,常表现为系统无响应、命令执行缓慢或服务异常。它多源于CPU满载、内存耗尽、磁盘IO瓶颈或文件句柄泄漏,而非真正硬件故障。掌握系统负载分析、资源定位和现场数据采集等方法,能有效缩短故障恢复时间。本文从通用排查思路出发,结合rsync复制卡死等典型场景,提供一套可落地的诊断流程,帮助运维人员在服务器投入现场前预判风险,从容应对各类卡死问题。

weixin_33908217的博客 341

Linux内存告警与OOM Killer排查:从free指标到cgroup限制的完整解读

在Linux服务器运维中,free命令显示的内存剩余量常让人误判系统真实负载。可用内存(available)与空闲内存(free)含义不同,前者是内核基于page cache、slab回收能力估算出的真实可分配量。当内存申请速度超过回收速度,overcommit机制就会触发OOM Killer挑选进程终止,而cgroup限制、堆外内存、Swap缺失等因素都会成为隐藏的内存杀手。通过dmesg日志、/proc/meminfo、oom_score等指标,可以定位进程被杀的具体原因,并结合systemd内存限制、

weixin_34037173的博客 299

Linux ps命令深度实战:20个生产环境进程诊断技巧

ps是Linux系统中最基础却最易被低估的进程状态查看工具,其本质是内核进程数据结构(/proc/[pid]/stat)的实时文本投影。它不依赖交互终端、无需额外安装,输出可直接管道化处理,是自动化运维与容器环境下的首选诊断入口。理解STAT状态码(如D不可中断睡眠)、RSS与VSZ内存差异、etime运行时长等核心字段,能精准识别僵尸进程、内存泄漏、CPU亲和性错配及IO阻塞等典型问题。本文聚焦真实故障场景,覆盖从基础进程定位、资源量化分析到容器穿透与安全审计的完整技术链路,助力工程师跨越‘能用’到‘精用

weixin_34396103的博客 447

Hive故障排查实战:从YARN资源到元数据一致性的分层诊断与恢复

在大数据生态中,数据仓库的稳定运行是保障下游分析、报表和机器学习流水线的基石。其核心原理在于协调计算资源、元数据管理与查询执行等多个服务层,确保数据一致性与作业可靠性。这一架构的技术价值在于能够高效处理海量数据,但复杂的依赖关系也带来了独特的故障排查挑战。常见的应用场景包括ETL任务失败、查询无响应或结果异常,这些问题往往涉及资源调度、服务连接与状态同步。本文聚焦于Hive这一广泛使用的数据仓库工具,深入解析其分层架构下的典型故障模式。针对计算资源层(如YARN队列资源耗尽、任务OOM)、元数据服务层(如M

dgqvhtlwq472235338的博客 414

Linux系统暗坑排查:从磁盘inode到网络TIME_WAIT的隐藏故障指南

Linux 运维中,我们通常依赖 CPU、内存、磁盘空间等常规指标,但真正拖垮服务的往往是这些显性监控之外的“隐性问题”,如磁盘 inode 耗尽、文件已删但空间不释放、大量僵尸进程占据进程表、TIME_WAIT 连接堆积耗尽本地端口等。这些故障的共同特点是:面板指标看似正常,服务却已异常。要定位它们,需要深入理解 Linux 的文件系统、进程模型与 TCP 协议栈原理,并善用 lsof、df -i、ps、ss 等底层工具。掌握这些排查方法,能帮助你在高并发或长期运行的服务器上,快速识别磁盘假释放、句柄泄漏

weixin_34343308的博客 409

Ubuntu 18.04 搭建 Minecraft 服务器实战指南:Java 17、screen 与系统兼容性精解

Minecraft 服务器本质是基于 Java 的长期运行进程,其稳定性高度依赖操作系统底层支持。在 Ubuntu 18.04 这类已停止标准维护(EOL)的 LTS 系统中,Java 版本兼容性、进程守护机制和内存管理构成三大技术瓶颈——官方要求 Java 17,但系统源仅提供 OpenJDK 8/11;systemd 和 Docker 因内核与组件版本过旧易触发崩溃;而 screen 成为少数能稳定维持后台会话的轻量级方案。本文聚焦真实部署场景,解析 Java 17 手动编译与环境隔离原理、server

weixin_30701575的博客 468

Agent死循环:五大成因、排查心法与架构免疫实践

在分布式系统和异步任务处理中,Agent(代理)作为核心组件,负责监听与处理事件,其稳定运行至关重要。其工作原理通常基于事件驱动或轮询模型,从消息队列或数据库获取任务并执行。然而,不当的状态管理、异常处理或外部依赖交互,极易导致Agent陷入“死循环”——即持续无效处理同一任务,耗尽CPU等系统资源,引发服务雪崩,技术价值在于保障系统高可用与资源效率。典型的应用场景包括订单处理、数据同步、消息消费等后台服务。本文聚焦Agent死循环这一典型故障,深入剖析其背后常见的五大成因,例如状态更新非原子性、异常被静默

weixin_33850015的博客 316

Docker核心名词实战解析:从镜像分层到容器隔离的故障排查地图

Docker不是简单的进程封装或镜像打包,而是基于Linux内核Namespace、Cgroups、Rootfs和OCI标准构建的资源隔离与调度体系。理解镜像分层(Layer)、容器运行时(Run-time)、网络模式(bridge/host)和卷(Volume)等核心概念,是解决OOM killed、Connection refused、port already in use等高频问题的前提。这些名词背后对应着真实的资源生命周期——从构建时的缓存复用、运行时的内存限制与PID 1管理,到协同态下的DNS解

weixin_34274029的博客 365

运维记录--K8S中java程序频繁死掉killed

上周上线完之后,平台频繁出现问题,从服务器查看pod状态为Running 但是从日志中查看就是直接被killed 检查过nginx日志、数据库等未发现异常 由上图可以看出最后直接就是被killed 下意识的我会以为是程序运行超过了所指定的Xmx参数,但是平台运行的情况我还是了解的,之前即便访问量大的是的也是个别服务或者数据库压力大,不会导致这两天无规律性质的死掉服务,几乎什么服务都可能会进行被killed 我尝试调整过启动脚本Xmx参数 但是没用,一样还是会被killed 之前也处理过关于pod启动异常的

小啊宇的博客 2043

Docker容器资源限制实战:CPU、内存、磁盘IO配置与应急排查指南

容器并非虚拟机,它共享宿主机内核,一旦资源失控,可能导致整个服务雪崩。cgroup与namespace提供了底层隔离机制,但默认不限制CPU和内存的配置,容易让一个异常容器拖垮全站。在生产环境中,合理设置--cpus、--memory等参数,配合日志轮转与磁盘配额,是保障多容器共存稳定性的关键。面对线上故障,掌握docker stats、top、strace、perf等排查工具,并熟悉docker update限流、fast止血流程,可以快速恢复服务。本文从资源限制原理出发,结合开源软件(MySQL、Red

weixin_34088583的博客 391

第17篇:深入解析OpenEuler 24.03系统中的逻辑卷管理(LVM)

OpenEuler 24.03系统中的逻辑卷管理(LVM)提供了灵活的存储管理方案,通过在物理存储与文件系统间构建抽象层实现动态资源分配。

专注于系统运维、数据库、DevOps、虚拟化技术、docker、kubernetes、等云原生技术。 1689

土豆服务器自救指南:低配机器性能优化全攻略

低配服务器常被戏称为“土豆服务器”,指CPU、内存、磁盘IO等资源捉襟见肘的廉价云主机或VPS,在并发稍高时便出现响应慢、掉线甚至服务崩溃等问题。但性能短板并非无解,通过科学的系统体检、合理的部署方式、针对性的压测验证和分层级的优化策略,完全能让这类机器稳定承担业务流量。本文从基础设施检查、systemd守护、Nginx反向代理,到接口限流、数据库慢查询治理、批量任务防重叠,再到监控告警与常见故障排查,提供一套完整可落地的工程实践方案。无论是1C2G的入门云主机,还是2C4G的小服务器,只要按此流程操作,就

weixin_30399155的博客 413

经典脉冲激光测距原理&雷达方程

脉冲激光测距机的工作过程如下:首先用瞄准光学系统瞄准目标,然后接通激光电源,储能电容器充电,产生触发闪光灯的触发脉冲,闪光灯点亮,激光器受激辐射,从输出反射镜发射出一个前沿陡峭、峰值功率高的激光脉冲,通过发射光学系统压缩光束发射角后射向目标。通过计算激光发射功率经介质传输的衰减,目标表面截获和反射的光功率,到达接收视场的光功率,以及接收光学系统接收到的光功率,就可以得到到达光电探测器的光功率,即接收功率。⑤光東路程上的折射率变化;),测量光脉冲到达目标并由目标返回到接收机的时间,由此计算出目标的距离。

weixin_46153372的博客 2521

Unity中5自由度机械臂运动控制与夹爪交互仿真实践

本文详细介绍了在Unity中实现5自由度机械臂运动控制与夹爪交互仿真的完整流程。从模型导入、物理组件配置到关节运动控制算法(包括逆运动学IK),再到夹爪抓取逻辑和工业分拣案例实战,提供了可落地的代码示例与性能优化方案,助力开发者快速掌握机械臂仿真核心技术。

weixin_29021757的博客 446
上一篇: Linux下如何获取程序的进程号?
下一篇: JPA按照实体类的字段顺序生成表
程序员青戈
程序员青戈 领域专家: 后端开发技术领域 领域专家: 后端开发技术领域
博客等级 码龄10年 3万+粉丝 250原创
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

程序员青戈

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值