为什么我的Java应用内存溢出时会被Docker Kill掉？
像我们这样在Docker中运行Java应用程序的人，可能已经遇到过JVM在容器中运行时无法准确检测可用内存的问题。jvm没有准确地检测Docker容器中可用的内存，而是查看机器的可用内存。这可能导致在容器内运行的Java应用程序在尝试使用超出Docker容器限制的内存量时被终止的情况。 jvm对可用内存的错误检测与Linux工具/lib有关，这些工具/lib是在cgroups存在之前创建的，用于返
Java内存泄漏检测库LeakCanary介绍
LeakCanary：Android和Java的内存泄漏检测库。 java.lang.OutOfMemoryError at android.graphics.Bitmap.nativeCreate(Bitmap.java:-2) at android.graphics.Bitmap.createBitmap(Bitmap.java:689) at com.squareup.ui.SignView
Java堆转储dump文件的几种方法
在本文中，我们将展示用Java捕获堆转储的不同方法。 堆转储是JVM内存中某一时刻所有对象的快照。它们对于解决内存泄漏问题和优化Java应用程序中的内存使用非常有用。 堆文件通常以二进制格式存储。我们可以使用jhat或JVisualVM之类的工具打开和分析这些文件。另外，对于Eclipse用户来说，使用MAT是非常常见的。 下面我们将介绍生成堆转储的多种工具和方法，并将展示它们之间的主要区别。 J
内存溢出怎么解决
对OOM错误和堆分析的深入研究将帮助您确定Java应用程序内存问题的根本原因，并指导您了解GC。 任何使用过基于Java的企业级后端应用程序的软件开发人员都会遇到来自客户或QA工程师的这一臭名昭著或尴尬的错误：java.lang.OutOfMemoryError：Java heap space。 为了理解这一点，我们必须回到计算机科学的基本原理算法的复杂性，特别是“空间”复杂性。如果我们还记得，每
java 内存泄露
缺乏经验的程序员通常认为Java的自动垃圾收集完全可以让他们从内存管理的担忧中解脱出来。这是一种常见的误解：当垃圾收集器尽其所能时，即使是最好的程序员也完全有可能成为严重内存泄漏的牺牲品。让我解释一下。 当不必要地维护不再需要的对象引用时，会发生内存泄漏。这些泄漏很严重。首先，当你的程序消耗越来越多的资源时，它们会给你的机器带来不必要的压力。更糟糕的是，检测这些泄漏可能很困难：静态分析通常难以精确
JVM Metaspace内存溢出排查与总结
一. 现象 前段时间公司线上环境的一个Java应用因为OOM的异常报警，导致整个服务不可用被拉出集群，本地模拟重现的现象如下: 当时的解决方案是增加metaspace的容量：-XX:MaxMetaspaceSize=500m，从原来默认的256m改为500m，虽然没有再出现oom，但这个只是临时解决方案，通过公司的监控系统观察metaspace的使用情况还是在上升，而且后面随着业务访问量越来越大还
在这个努力程度如此低下的时代，还轮不到比拼天赋。静下心来，just do it
更多干货请关注公众号【Java老K】
录制线上真实流量在测试环境进行回放，对比差异
特点：
无代码侵入的数据采集和Mock，支持Spring、Dubbo、Redis、Mybatis等开源框架的录制和回放；
支持各种复杂业务场景的验证：多线程并发、异步回调、写操作等；
欢迎扫码进QQ群交流