Linux服务自动掉线问题排查,都是僵尸惹的祸(2)

内存

核心问题：物理内存耗尽

最突出、最紧急的问题是内存使用情况：

• 总内存：30932.4 MiB（约30.9 GB）

• 已用内存：28177.6 MiB（约28.2 GB）—— 使用率高达 91.1%

• 可用内存（avail Mem）：只有 2253.5 MiB（约2.2 GB）

• 空闲内存（free）：仅剩 291.6 MiB（约0.3 GB）

内存压力很大.而且Java服务在内存做计算等时,就会导致Out-Of-Memory (OOM) Killer 被触发,就会kill服务.

02

—

内存消耗大户

大部分 Java 服务 CPU 占用率较低（0.X%），内存占用（%MEM）在 3.3% 到 11.5% 之间，这取决于具体的业务负载和 JVM 内存设置。

由此我们可以看出.Java服务中使用了大量的内存处理操作:

• 查 (Query/Read)：

• 表现：根据 ID 查询单条、分页查询。

• 内存影响：中低。只要分页参数合理（每页 10~100 条），内存消耗可控。

• 风险点：如果业务代码写成了“全表查询到内存中再过滤”（例如 select * from table 不加限制），或者分页深度过大（如 offset 1000000），会导致大量数据被加载到堆内存中（List/Map），造成 Young GC 频繁。

• 数据导出 (Export)：

• 全量查询：通常导出需要查询大量数据（几万甚至几十万条记录）。

• 对象持久化：查出来的每一条数据都要被映射成 Java 对象（POJO/Entity）。如果一次性将 10 万条记录查出来放到一个 List 里，这 10 万个对象瞬间就会把 Java 堆内存 (Heap) 撑爆。

• Excel/CSV 构建：如果使用 Apache POI 的 SXSSFWorkbook (普通模式) 或 EasyExcel 的非流式模式，导出的整个 Excel 表格对象也会全部驻留在内存中，这是双重暴击。

• 数据导入 (Import):

• 前端上传文件：文件先转换成 MultipartFile 流，如果不做限制，几十 MB 的 Excel 文件可能直接被读入内存。

• 解析数据：读取 Excel 时，若直接解析整个文件并转换为巨大的 Java 对象 List 进行业务校验，会极大消耗内存。

• 批量插入：为了效率，程序通常使用 insert batch。但如果在内存中拼装了超大的 SQL 预编译参数数组，也会占用内存。

• 文件上传 (File Upload)：

• 如果您直接使用 MultipartFile.getBytes() 把整个文件读到 byte[] 数组里

• 上传 100MB 的视频，内存里立刻多出 100MB 的 byte[]

  Java 的 byte[] 分配和回收非常消耗时间，极易引发 Full GC，导致服务停顿。

• 如果您直接使用 MultipartFile.getBytes() 把整个文件读到 byte[] 数组里：

• 如果需要把文件转存到 OSS 对象存储（阿里云 OSS），标准做法是上传 InputStream。

• 未关闭的 IO 流

• 内存泄漏

   使用了 ThreadLocal 但未清理，导致长生命周期线程关联了大对象无法被 GC

• Websocket

• 原理：每一个 WebSocket 客户端连接，服务器端都需要维护一个对应的 Session 对象（或 Channel 对象）。

• 内存占用：单个连接的对象开销不大（通常几十到几百字节），但连接数一旦变大，这个消耗就会线性增长。

拈㕦一笑的CSDN

https://blog.csdn.net/u013432938?type=blog