企业官网建设流程全解析

一个域名怎么做两个网站,四川遂宁做网站的公司,学校网站平台建设,wordpress mysql 安装一、首先#xff0c;理解 OOM 的类型 OOM 错误并非只有一种#xff0c;明确错误类型是排查的第一步。常见的 OOM 类型及原因#xff1a; java.lang.OutOfMemoryError: Java heap space 原因#xff1a;堆内存不足。这是最常见的 OOM#xff0c;表示创建的新对象无法在堆中…一、首先理解 OOM 的类型OOM 错误并非只有一种明确错误类型是排查的第一步。常见的 OOM 类型及原因java.lang.OutOfMemoryError: Java heap space原因堆内存不足。这是最常见的 OOM表示创建的新对象无法在堆中分配足够空间。java.lang.OutOfMemoryError: Metaspace(Java 8) /PermGen space(Java 7-)原因元空间或永久代不足。元空间用于存储类的元数据如类名、方法信息、字节码等。通常由动态类生成如大量使用 CGLib、反射、JSP或部署了大量应用导致。java.lang.OutOfMemoryError: Unable to create new native thread原因创建的线程数超过系统限制。可能因为应用创建了太多线程或者系统如 Linux给每个进程的线程数限制ulimit -u过低。java.lang.OutOfMemoryError: GC overhead limit exceeded原因GC 开销过大。JVM 花费了超过 98% 的时间进行垃圾回收但只回收了不到 2% 的堆空间意味着 GC 在做无用功应用基本已无法推进。java.lang.OutOfMemoryError: Requested array size exceeds VM limit原因尝试分配一个大于 JVM 允许的最大数组大小通常是Integer.MAX_VALUE - 2。二、排查工具一览工具用途特点JVM 内置参数记录关键信息无需额外工具必须在启动前配置jps查看 Java 进程号基础命令行工具jstat监控 GC 状态轻量级实时查看 GC 和内存分区使用情况jmap生成堆转储文件获取堆内存快照用于离线分析jstack生成线程转储文件分析线程状态排查死锁或线程过多问题VisualVM图形化监控和分析JDK 自带功能全面直观易用Eclipse MAT分析堆转储文件分析 Heap Dump 的首选工具强大且高效Arthas在线诊断工具阿里开源无需重启项目动态诊断神器三、具体排查步骤从易到难阶段一初步诊断与信息收集确认 OOM 类型仔细阅读错误日志的第一行确定是哪种OutOfMemoryError。这直接决定了后续的排查方向。添加 JVM 参数最重要的步骤在应用启动时添加以下参数以便在下次出现 OOM 时自动捕获关键信息。-XX:HeapDumpOnOutOfMemoryError # 在发生OOM时自动生成堆转储文件Heap Dump-XX:HeapDumpPath/path/to/dump.hprof # 指定Heap Dump的保存路径-XX:PrintGCDetails # 打印详细的GC日志-Xloggc:/path/to/gc.log # 将GC日志输出到文件如果已经发生了 OOM 但没有这些参数请务必加上它们然后重现问题。监控实时状态使用jps找到应用的进程 ID (PID)。使用jstat -gc pid 1000每秒钟一次来监控堆内存各分区Eden, Old等的使用情况和 GC 次数/时间。如果老年代OGC/UGC使用率持续居高不下且频繁 Full GC说明很可能有内存泄漏。阶段二深度分析 - 针对Java heap space和Metaspace核心工作分析 Heap Dump获取 Heap Dump自动生成通过上述-XX:HeapDumpOnOutOfMemoryError参数OOM 时自动生成。手动生成使用jmap命令在任意时间点手动生成。jmap -dump:live,formatb,filedump.hprof使用 MAT 分析 Heap Dump将.hprof文件导入 Eclipse Memory Analyzer Tool (MAT)。第一步查看Leak Suspects Report泄漏嫌疑报告。MAT 会自动分析并给出可能发生内存泄漏的疑点这是最快最有效的入门方法。第二步使用Histogram直方图功能。查看哪些类的对象数量最多、占用内存最大。重点关注Shallow Heap和Retained Heap大的类。Shallow Heap: 对象本身占用的内存。Retained Heap: 该对象被回收后能连带释放的总内存这是关键指标。第三步对疑似有问题的类右键选择Merge Shortest Paths to GC Roots-exclude all weak/soft references。这会显示这些对象为什么没有被垃圾回收——即是谁在持有它们的强引用Strong Reference。这个引用链的根部通常就是问题的根源如某个全局的静态集合、未关闭的连接等。分析 GC 日志使用 GCeasy 或 GCHisto 等在线/离线工具上传gc.log文件。它们可以生成可视化报告帮你判断内存分配速率是否过高GC 效率如何平均暂停时间多久是否发生了内存提升Promotion Failure或疏散失败Evacuation Failure对于MetaspaceOOM使用jstat -gc pid查看MC(Metaspace Capacity) 和MU(Metaspace Usage) 的使用情况。检查是否使用了大量动态代理、反射如 Spring AOP、或热部署。可以考虑适当调大元空间大小但仅是临时方案-XX:MaxMetaspaceSize256m阶段三针对其他类型 OOMUnable to create new native thread:使用jstack pid导出线程转储查看线程数量和工作状态。检查代码中是否有线程创建未正确关闭的情况例如使用线程池而非无限循环new Thread()。检查系统级的线程数限制Linux 下使用ulimit -u查看。GC overhead limit exceeded:排查思路与Java heap space类似这通常是内存泄漏的一个极端表现。同样需要分析 Heap Dump 找到无法回收的对象。四、常见原因与修复策略内存泄漏这是最普遍的根源。场景静态集合类持有了大量对象引用且未及时清理未关闭的资源数据库连接、文件流、网络连接监听器注册后未注销内部类持有外部类的引用等。修复根据 MAT 找到的引用链修复代码在适当的地方释放引用如调用remove(),close()方法。堆内存设置过小场景应用本身确实需要大量内存如处理大文件、大数据集但-Xmx参数设置太小。修复根据监控情况合理调大堆内存参数-Xms,-Xmx。代码问题场景循环中创建大量对象使用了不合理的数据结构用HashMap存储少量数据但初始化容量initialCapacity巨大。修复优化代码逻辑避免不必要的对象创建重用对象使用对象池。配置-XX:HeapDumpOnOutOfMemoryError是重中之重有了 Heap Dump问题就解决了一半。