一次频繁fullgc但内存不下降

最新推荐文章于 2023-08-04 08:32:00 发布
最新推荐文章于 2023-08-04 08:32:00 发布
阅读量656 收藏
点赞数
分类专栏： jvm
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/kobexzf/article/details/114586314
版权

mat显示beanFactory retainedHeap大，List Objects with outgoing references 显示dependentBeanMap的retainedHeap大，本地debug分析

struts2-spring通过StrutsSpringObjectFactory(ObjectFactory)来进行对象创建
对象如action由Spring创建(beanDefinition和singletonObjects都不会保留，简单来说只是借用spring创建对象的能力创建对象)
对象的autowire也由Spring负责，装配成功action对象的依赖关系会保留在dependentBeanMap和dependenciesForBeanMap(这样不好，但没办法)
byType：类型命中了resolvableDependencies(ServletRequest,HttpSession,BeanFactory等)，特殊处理如BeanFactory直接注入，ServletRequest通过jdk代理（底层通过threadlocal拿请求）注入，代理的实例和名称每次都不一样，两张map会不断增长
byName：通过名称容易找不到，装配难成功，依赖关系不易保留

kobexzf
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
运维：你们 JAVA 服务内存占用太高，还只增不减！告警了，快来接锅
qq826654664jx的专栏
05-24 5120
先点赞再看，养成好习惯 某天，运维老哥突然找我：“你们的某 JAVA 服务内存占用太高，告警了！GC 后也没释放，内存只增不减，是不是内存泄漏了！” 然后我赶紧看了下监控，一切正常，距离上次发版好几天了，FULL GC 一次没有，YoungGC，十分钟一次，堆空闲也很充足。 运维：“你们这个服务现在堆内存 used 才 800M，但这个 JAVA 进程已经占了 6G 内存了，是不是你们程序出啥内存泄露的 bug 了！” 我想都没想，直接回了一句：“不可能，我们服务非常稳定，不会有这种问题！” .
GCViewer-FullGC分析工具
10-11
然而，当GC运行频繁或出现长时间的Full GC时，可能会导致应用程序性能下降，甚至出现暂停现象。这时，我们需要对GC日志进行深入分析，以优化程序性能。GCViewer就是这样一款强大的工具，它专门用于可视化分析Java...
出大事了，涛哥你们Java应用GC后不释放内存
xmt1139057136的专栏
06-17 4798
你知道的越多，不知道的就越多，业余的像一棵小草！成功路上并不拥挤，因为坚持的人不多。编辑：业余草blog.csdn.net/qq_40378034推荐：https://www.xttblo...
记一次线上FullGC问题排查
weixin_39658449的博客
05-15 634
问题起因 2022-03-13在钉钉工作通知中收到申请其中一台机器的预警。预警信息显示FullGC的次数持续超过指定的阈值。 我们知道FullGC非常耗时。当一个GC线程执行FullGC时，会严重影响其他线程的正常工作，造成系统卡顿的现象。通常情况下，它被认为可以停止这个世界。 所以这台机器果断重启，但是没过多久，其他机器就开始陆续报出FullGC警告。实在没办法，于是重启了整个应用，重启后应用运行恢复正常。虽然暂时恢复正常了，但不能保证以后不会再出问题，所以要追根溯源，从根源上解决问题。 .
系统频繁Full gc问题分析及解决办法
热门推荐
n8765的专栏
03-17 2万+
一、场景描述 上周开始系统在业务高峰期一直收到Full gc报警，监控显示fgc频繁，下图是监控图，左边红框是优化前效果，右边是优化后，优化后fgc基本为0   二、原因查找 1.查看gc日志，发现old区fgc后大小没有变化，如下图： 2.去线上dump内存看是什么对象，用memory analyzer分析，Retained Size竟然有2.4G，全是sun.awt.SunToo
一次Full GC导致CPU飙升的排查过程
AlbenXie的博客
05-04 1010
我们决定调整jvm参数，扩大内存，修改jvm垃圾收集器，扩大内存后，后面还是出现了该问题，不过这次只是cpu飙升，系统没有出现卡顿，出现问题后，我们使用如下命令，查看jvm堆内存快照，线程堆栈，等信息。因为这次调整了堆内存大小，触发问题后，没有进行full gc，对象还在，查看内存对象占用比，发现相关代码问题，一次性加载了150万的实例到对象中，调整内存之前加载该对象后，导致内存飙升，触发gc，进而引起cpu使用率飙升。从监控看到，cpu，内存，磁盘，网络在异常发生时都有明显的抖动。
记一次频繁fullgc排查到解决全流程复盘
zhang09090606的博客
08-07 4526
阿里云oss文件上传导致的频繁fullgc问题排查到解决全流程复盘
java jstat 查看哪个进程频繁GC垃圾回收
11-09
当我们遇到应用程序性能下降或者内存消耗过快的问题时，就需要关注哪个进程在频繁进行GC操作。下面我们将详细探讨如何使用`jstat`工具以及通过配置GC日志来分析和优化Java进程。 `jstat`是Java虚拟机内置的一个...
MemoryAnalyzer-1.8.0.20180604-linux.gtk.x86_64.zip
03-21
通过深入理解MAT的各种视图和功能，开发者可以有效地找出内存泄漏、内存溢出和频繁Full GC等问题，从而提升Java应用的性能和稳定性。在实际工作中，结合MAT进行内存分析，无疑是优化系统性能、保障服务稳定不可或缺...
weblogic内存调优
11-26
WebLogic服务器内存调优是一个关键的过程，以确保应用程序的稳定性和高效性。内存配置不当可能导致系统性能下降，甚至出现内存溢出错误。以下是对JVM内存原理和WebLogic内存调优的详细说明。 首先，JVM内存分为两大...
websphere内存溢出
04-11
4. **诊断过程**：首先，分析JVM的GC日志，观察是否存在频繁的Full GC或者长时间的GC暂停。其次，使用内存分析工具检查内存快照，查找长期驻留的对象和异常增长的数据结构。最后，定位可能导致内存泄漏的代码或配置...
Java Full GC (Ergonomics) 的排查
谈谈1974
04-05 1万+
文章目录1. Full GC (Ergonomics)1.1 Java 进程一直进行 Full GC1.2 Full GC 的原因1.3 检查堆占用2. 代码检查3. 解决方式 1. Full GC (Ergonomics) 1.1 Java 进程一直进行 Full GC 例行检查线上运行的 Java 服务，通过 jstat -gcutil < pid > 命令检查 gc 情况的时候发......
Java进行gc后堆内存降低但是Java进程的内存没有释放的原因
number_one2的博客
11-09 4158
Java进行gc后堆内存降低但是Java进程的内存没有释放的原因
[jvm]频繁full gc怎么优化
新一的技术笔记
09-01 3318
前言 今天被问到，如果频繁full gc怎么排查，怎么优化？ 服务要怎么来手动触发full gc呢？ 盲猜 频繁fullgc，那肯定是老年代不够用了； 所以要么就是有巨大对象老是塞进去，要么就是老年代的碎片严重； 使用工具抓一下内存，分析一下，哪些对象是最多的，是否合理。 老年代大小参数设置错误； 分析 如果是一次fullgc后，剩余对象不多。那么说明eden区设置太小，导致短生命周期的对象进入了old区。 如果一次fullgc后，old区回收率不大，那么说明old区太小。
关于压测结束后程序内存使用率不下降的问题记录
ancoa的博客
06-19 5406
JVM为什么不归还内存给操作系统？原来是我认识有误
linux下程序占用内存只涨不降原因追查
cleanfield的专栏
12-14 4799
linux下进程占用内存只增不减，如何定位问题，这里给出了一次追查过程
为什么jvm启动时，参数Xms指定的内存大小没有被占用
蒙牛真好的博客
09-21 4540
JVM参数设置为 -Xms4g -Xmx4g 最大堆内存和最小堆内存都设置了4G，但是为什么java进程占用的实际物理内存却没有占用4个G，却是随着进程的运行，不断的增长，直到触发FullGC，并且发生完FullGC之后，Java进程的内存却没有随之变小？ 问题1：为什么参数Xms指定的内存大小没有被占用 原因：JVM在启动前会向操作系统申请内存， 注意这个内存是虚拟内存，如果-Xms设置的过大，超过了操作系统可分配的内存上线，就会启动失败，报下面的异常 Error occurred during init
严重Full GC问题
最新发布
kankan_s的专栏
08-04 983
综上所述，针对Full GC导致系统卡死的问题，需要综合考虑堆内存大小、内存泄漏、大对象处理、Finalizer的使用以及并发线程数等因素，通过优化配置和代码改进，来降低Full GC的频率和影响，提高系统的稳定性和性能。内存泄漏：Full GC通常是在老年代进行的，如果应用程序存在内存泄漏问题，老年代的对象会持续增加，导致Full GC的时间越来越长，最终引发系统卡死。优化大对象的处理：对于频繁创建的大对象，可以考虑使用对象池或者重用对象，以减少Full GC的负担。
对象内存分配机制，看完再也不用怕full gc了
lisijing8201的博客
06-19 211
在生产环境中如果频繁出现full gc将会导致系统性能出现较为严重的下滑，而出现full gc的原因主要就是因为老年代空间不够用，所以解决问题的关键就是去分析为什么老年代的空间经常被占满。先来看一下对象内存分配的流程图： 在上一篇Java内存模型简介中有提到，当我们创建对象时是有可能分配在栈上的。一般情况下，我们创建的对象都会分配在堆内存中，当对象没有被引用的时候，需要依靠GC进行回收内存，如果对象数量较多的时候，会给GC带来较大压力，也间接影响了应用的性能。为了减少临时对象在堆内分配的数量，JVM通过逃逸
full gc多久一次算正常
06-29
Full GC（Full Garbage Collection）是Java虚拟机对堆内存进行全面清理和整理的过程，一般发生在垃圾回收器无法再回收更多的对象时。 Full GC的频率不是固定的，它取决于多个因素，包括堆的大小、对象的分配速度、垃圾回收器的选择等。一般来说，Full GC的发生频率应该尽量较低，因为Full GC会触发Stop-The-World（STW）暂停，导致应用程序的性能下降。 对于一个正常运行的Java应用程序，Full GC的发生频率通常应该是比较低的，例如每几小时或每几天。如果Full GC的频率过高，可能意味着存在内存泄漏或者堆内存设置不合理的情况，需要进行调优。 要确定Full GC的频率是否正常，可以观察应用程序的内存使用情况和GC日志，分析GC事件的发生时间和持续时间。如果发现频繁的Full GC现象，可以考虑进行堆内存大小的调整、检查代码中可能导致内存泄漏的地方，或者尝试使用不同的垃圾回收器等措施。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值