网站优化制作,东莞房价一览表,腾讯企点账户中心,个人dw网页设计线上YGC耗时过长优化方案有哪些#xff1f;
1. 如果生命周期过长的对象越来越多#xff08;比如全局变量或者静态变量等#xff09;#xff0c;会导致标注和复制过程的耗时增加 2. 对存活对象标注时间过长#xff1a;比如重载了Object类的Finalize方法#xff0c;导致标…线上YGC耗时过长优化方案有哪些
1. 如果生命周期过长的对象越来越多比如全局变量或者静态变量等会导致标注和复制过程的耗时增加 2. 对存活对象标注时间过长比如重载了Object类的Finalize方法导致标注Final Reference耗时过长或者String.intern方法使用不当导致YGC扫描StringTable时间过长。可以通过以下参数显示GC处理Reference的耗时-XX:PrintReferenceGC 3. 长周期对象积累过多比如本地缓存使用不当积累了太多存活对象或者锁竞争严重导致线程阻塞局部变量的生命周期变长 线上频繁FullGC优化方案有哪些
1. 线上频繁FullGC一般会有这么几个特征 1. 线上多个线程的CPU都超过了100%通过jstack命令可以看到这些线程主要是垃圾回收线程 2. 通过jstat命令监控GC情况可以看到Full GC次数非常多并且次数在不断增加 2. 排查流程 1. top找到cpu占用最高的一个 **进程id** 2. 然后 【top -Hp 进程id】找到cpu占用最高的 **线程id** 3. 【printf %x\n **线程id 】**假设16进制结果为 a 4. jstack 线程id | grep 0xa -A 50 --color 5. 如果是正常的用户线程 则通过该线程的堆栈信息查看其具体是在哪处用户代码处运行比较消耗CPU 6. 如果该线程是 VMThread则通过 jstat-gcutil命令监控当前系统的GC状况然后通过 jmapdump:formatb,file导出系统当前的内存数据。导出之后将内存情况放到eclipse的mat工具中进行分析即可得出内存中主要是什么对象比较消耗内存进而可以处理相关代码正常情况下会发现VM Thread指的就是垃圾回收的线程 7. 再执行【jstat -gcutil **进程id】, **看到结果如果FGC的数量很高且在不断增长那么可以定位是由于内存溢出导致FullGC频繁系统缓慢 8. 然后就可以Dump出内存日志然后使用MAT的工具分析哪些对象占用内存较大然后找到对象的创建位置处理即可
参考面试官如果你们的系统 CPU 突然飙升且 GC 频繁如何排查 如何解决线上gc频繁的问题
1. 查看监控以了解出现问题的时间点以及当前FGC的频率可对比正常情况看频率是否正常 2. 了解该时间点之前有没有程序上线、基础组件升级等情况。 3. 了解JVM的参数设置包括堆空间各个区域的大小设置新生代和老年代分别采用了哪些垃圾收集器然后分析JVM参数设置是否合理。 4. 再对步骤1中列出的可能原因做排除法其中元空间被打满、内存泄漏、代码显式调用gc方法比较容易排查。 5. 针对大对象或者长生命周期对象导致的FGC可通过 jmap -histo 命令并结合dump堆内存文件作进一步分析需要先定位到可疑对象。 6. 通过可疑对象定位到具体代码再次分析这时候要结合GC原理和JVM参数设置弄清楚可疑对象是否满足了进入到老年代的条件才能下结论。 如何进行线上堆外内存泄漏的分析Netty尤其居多
1. JVM的堆外内存泄露的定位一直是个比较棘手的问题 2. 对外内存的泄漏分析一般都是先从堆内内存分析的过程中衍生出来的。有可能我们分析堆内内存泄露过程中发现我们计算出来的JVM堆内存竟然大于了整个JVM的**Xmx**的大小那说明多出来的是堆外内存 3. 如果使用了 Netty 堆外内存那么可以自行监控堆外内存的使用情况不需要借助第三方工具我们是使用的“反射”拿到的堆外内存的情况 4. 逐渐缩小范围直到 Bug 被找到。当我们确认某个线程的执行带来 Bug 时可单步执行可二分执行定位到某行代码之后跟到这段代码然后继续单步执行或者二分的方式来定位最终出 Bug 的代码。这个方法屡试不爽最后总能找到想要的 Bug 5. 熟练掌握 idea 的调试让我们的“捉虫”速度快如闪电“闪电侠”就是这么来的。这里最常见的调试方式是**预执行表达式**以及通过**线程调用栈**死盯某个对象就能够掌握这个对象的定义、赋值之类 6. 在使用直接内存的项目中最好建议配置 -XX:MaxDirectMemorySize设定一个系统实际可达的最大的直接内存的值默认的最大直接内存大小等于 -Xmx的值 7. 排查堆外泄露建议指定启动参数 -XX:NativeMemoryTrackingsummary - Dio.netty.leakDetection.targetRecords100-Dio.netty.leakDetection.levelPARANOID后面两个参数是Netty的相关内存泄露检测的级别与采样级别
参考Netty堆外内存泄露排查盛宴 - 美团技术团队
Netty 是一个异步事件驱动的网络通信层框架用于快速开发高可用高性能的服务端网络框架与客户端程序它极大地简化了 TCP 和 UDP 套接字服务器等网络编程。
Netty 底层基于 JDK 的 NIO我们为什么不直接基于 JDK 的 NIO 或者其他NIO框架
使用 JDK 自带的 NIO 需要了解太多的概念编程复杂。Netty 底层 IO 模型随意切换而这一切只需要做微小的改动。Netty自带的拆包解包异常检测等机制让我们从 NIO 的繁重细节中脱离出来只需关心业务逻辑即可。Netty解决了JDK 的很多包括空轮训在内的 Bug。Netty底层对线程Selector 做了很多细小的优化精心设计的 Reactor 线程做到非常高效的并发处理。自带各种协议栈让我们处理任何一种通用协议都几乎不用亲自动手。Netty社区活跃遇到问题随时邮件列表或者 issue。Netty已经历各大RPC框架Dubbo消息中间件RocketMQ大数据通信Hadoop框架的广泛的线上验证健壮性无比强大。 线上元空间内存泄露优化方案有哪些 需要注意的一点是 Java8以及Java8的JVM已经将永久代废弃了取而代之的是元空间且元空间是不是在JVM堆中的而属于堆外内存受最大物理内存限制。最佳实践就是我们在启动参数中最好设置上 -XX:MetaspaceSize1024m -XX:MaxMetaspaceSize1024m。具体的值根据情况设置。为避免动态申请可以直接都设置为最大值 元空间主要存放的是类元数据而且metaspace判断类元数据是否可以回收是根据加载这些类元数据的Classloader是否可以回收来判断的只要Classloader不能回收通过其加载的类元数据就不会被回收。所以线上有时候会出现一种问题由于框架中往往大量采用类似ASM、javassist等工具进行字节码增强生成代理类。如果项目中由主线程频繁生成动态代理类那么就会导致元空间迅速占满无法回收
参考一次完整的JVM堆外内存泄漏故障排查记录 - 知乎
