交互式网站是什么意思,美术学院网站建设,山西又增一例在忻州,行情软件排行榜前十名前序
在武侠编码的江湖中#xff0c;内存泄漏犹如隐秘杀手#xff0c;潜伏于应用程序的各个角落#xff0c;悄无声息地吞噬着系统资源。若不及时发现和解决#xff0c;必将导致内存枯竭#xff0c;应用崩溃。
背景#xff1a;内存泄漏的由来 内存泄漏#xff0c;乃程序…前序
在武侠编码的江湖中内存泄漏犹如隐秘杀手潜伏于应用程序的各个角落悄无声息地吞噬着系统资源。若不及时发现和解决必将导致内存枯竭应用崩溃。
背景内存泄漏的由来 内存泄漏乃程序运行过程中已不再使用的内存块未被及时回收导致内存使用量不断增加的现象。此问题多发于对象生命周期管理不当之处如持有对象引用过长或未能及时释放资源终致内存枯竭系统崩溃。
在JVM的世界中内存泄漏常见于以下几种情况
静态集合类如 HashMap、ArrayList 等若不断向其添加对象而不清理易造成内存泄漏。长生命周期对象持有短生命周期对象引用如单例模式中的对象持有临时对象引用导致临时对象无法被垃圾回收。未关闭的资源如数据库连接、文件流等若未及时关闭亦会导致内存泄漏。监听器与回调函数未及时移除的监听器或回调函数可能导致对象无法被回收。
解决方案内存泄漏的破解之道 善用工具探查隐患 如同侠客需借助兵器程序员亦需运用内存分析工具如 jvisualvm、jmap、jhat 等探查内存使用情况定位内存泄漏之源。常规步骤如下 使用 jmap 生成堆转储文件jmap -dump:live,formatb,fileheap_dump.hprof 使用 jvisualvm 或 Eclipse MAT 分析堆转储文件查找无法回收的对象。 优化代码清理内存 针对发现的内存泄漏问题需优化代码确保对象在不再使用时尽快释放。具体方法如下 及时清理集合对于使用完毕的对象及时从集合中移除。合理管理对象引用避免长生命周期对象持有短生命周期对象引用可使用弱引用WeakReference来管理。关闭资源对于文件流、数据库连接等资源在使用完毕后务必调用 close() 方法关闭。移除监听器在适当时机移除不再需要的监听器或回调函数。 加强监控防患未然
如同江湖侠客需时刻警惕程序员亦需持续监控内存使用情况防患于未然。可使用监控工具如 Prometheus、Grafana 等实时查看内存使用情况及时发现异常。
滴滴滴、滴滴滴…,代码剑宗中的某一处洞府中的告警声不绝于耳近眼望去洞府正中央的蒲团上正坐着一位双眼紧闭身材健硕的男子此男子的旁边还摆放着篮球、杠铃等道具从洞府的摆布不难看出此男子平日经常锻炼以至于他的身型较于常人更加挺拔高大。男子听到告警声睁开双眼男子双眸中充满精光看来此次闭关男子有了不少收获。听到警告声的男子眼神中闪过了一丝不耐烦嘴里轻轻碎了一声然后不紧不慢地从袖中拿出一个圆盘此圆盘此时一直闪烁着红光并且一直发出“滴滴滴”的声音男子用手轻抚手中圆盘身前映射出一个巨大光影光影里面有一些画面跟文字男子大概花了一刻钟时间扫描完光影里的内容。他脸上闪过一丝苦涩然后说道“该死的竟然出现了内存告警”随即只见男子双手一挥把光影打散男子站了起来朝着旁边的一个房间走去。
而洞府中的男子就是咱们的男主“阿强”。他之前正坐在蒲团上修炼内功到一个关键时刻不曾想被圆盘的告警打断此时的阿强心情不是很美丽…
内存紧急处理
阿强离开洞府的第一件事情就是通过告警身份牌进入“乾坤内存法阵”查看告警的应用阵脚阿强查看应用的内存情况跟系统的一些指标如下图所示阿强看到这个内存水位情况就发现了不对劲。应用从晚上03:00开始到目前为止内存一直处于一个缓慢上升状态。不过此时阿强倒也没有因此慌了自己阵脚阿强根据以前处理类似问题的经验他先通过“乾坤内存法阵”中的应用内存Dump导出功能先将内存快照给dump下来然后就将应用的容器进行重启的操作。
实时区间热点图
实时线程数 实时gc数量 实时堆内存信息 容器实时内存情况 不久应用的快照文件就dump了下来阿强看着dump下来的文件并没有直接去分析而是优先去询问了负责此应用的人询问了一下具体情况。2个时辰后阿强大概从负责此应用的人口中知道了此应用的基本情况。此应用名叫G服务是从F服务中拆出来的一个应用拆出来的G服务的代码内容与G服务是保持一致的但是G服务的内存表现很稳定并没有F服务表现出来的内存缓慢爬升的情况而G服务表现内存缓慢爬升则是随着不断提高流量灰度的一同上升的。其中F服务的一个容器内存情况大致是8台内存16G的云服务器G服务的容器内存情况是4台8G的云服务器。还有一个值得注意的一个点则是G服务的调用链路由于处于流量切换的过程与在F服务中不同其区别如 其中橙色的线表示G服务从F服务拆分出来后多一次交互也就是说在流量切换灰度期间G服务的流量入口是从F服务通过rpc接口方式接受的。
此时的阿强大概了解了G服务应用的基本情况接下来要做的事情则是去分析内存缓慢爬升的问题只见他拿出了一法器此法器名叫“乾坤内存镜”此法器的作用就是能够清晰地分析应用内存快照文文件在使用法器有一个细节问题需要注意的是如果通过此法器直接去打开内存快照文件此法器会默认进行fullgcfullgc后的快照文件如下图 fullgc后的快照文件内存大小明显和实际占用不同如果想让法器打开快照文件不尽兴fullgc则只需要换一种打开方式打开方式如下 此时你应该能看到如下图的内容说明此次打开方式没有尽兴fullgc我们只需要稍等片刻即可 通过这种方式打开的快照文件则是如下所示 阿强看着解析出来的快照内容此时展现出来内容是通过内存的实例的数量来进行的排序其中char[]占用了1412m大小的内存粗略看下来没有什么大对象。如果是几年前的阿强他会傻不拉几地去查看char[]实例的引用但是此时的阿强已经不是两年前的阿强经过时长两年半的练习他踩过数不清的坑经验告诉他此时你应该看看第三个实例,阿强此时查看第三个实例的Merged outgoing references他看到此实例的引用 然后再进一步跟进String的引用除了spring的常规引用发现logback和jackson有引用大量的字符实例。 阿强此时通过idea打开了G服务的代码开始查看起来jackson和logback的代码使用点2个时辰后阿强发现了一些奇怪的日志打印如下
log.info(业务接口处理请求参数明文{}, http request method:{},JSON.toJSONString(request.getParams()), methodMapping.getMethod());上面这种日志打印会将整个请求的入参都打印出来而且一次请求类似这种打印全部请求入参的日日志大概有57次而由于G服务的承载的业务请求报文都是比较大的也就是说每一次请求过来这种大日子的打印会打印好几次而这些大而全的日志大部分内容是没用的并且每次打印生成的字符串每次都是不同的也就是每次请求在堆内存中生成67个大字符对象这种大字符对象会在堆中频繁创建会造成youngc很频繁。而youngc过于频繁会造成很多大字符对象进入老年代导致整个堆内存不断上升。为了验证自己的猜想阿强尝试着删除G服务中这些大日志的打印最终发现内存上升的情况有一定的改善此时的内存已经不会出现缓慢爬坡的情况但是内存表现相比较F服务还是没有那么好的因此阿强又只能进一步去分析内存块照文件2刻钟后阿强在线程ThreadLocal中发现很多大char[]数组的引用而这些ThreadLocal都是由rpc线程所持有。 而rpc底层的序列化正是使用的jackson而com.fasterxml.jackson.core.util.BufferRecycler 是 Jackson 库中的一个工具类用于高效地管理和重用缓冲区。在多线程环境中特别是使用 ThreadLocal 时确实有可能导致内存泄漏
ThreadLocal 的生命周期问题ThreadLocal 变量会与线程的生命周期绑定如果线程不被回收ThreadLocal 变量及其引用的对象也不会被回收可能导致内存泄漏。缓冲区的大小和数量如果缓冲区的大小或数量非常大且这些缓冲区长期占用内存而不被释放可能导致内存使用过多从而引发内存泄漏。线程池使用不当在使用线程池时如果没有正确管理线程池的生命周期和资源可能会导致线程无法被回收进而导致 ThreadLocal 引用的对象无法被回收。
到这里真相大白而阿强面对涉及基础设施的改造他有点烦躁。凡是涉及基础设施的改动任务的难度和解决时间就会成倍增加因为基础设施的改造流程会拉的比较长。但这个任务是一个紧急的任务为了快速地将问题处理那怎么能够不去改造基础设施并解决这个问题呢阿强脑子在飞速的运转不多时阿强心中闪过一丝光亮他紧皱的眉间也开始舒坦。刚刚的那一丝光亮就是快速解决任务的关键那就是“类加载器的双亲委派机制”
