铁锚的CSDN博客

本文详细介绍怎样配置G1垃圾收集器的参数，如何进行性能调优, 以及如何对GC性能进行分析和评估。G1的全称为 Garbage First Garbage Collector, 是一款内置在HotSpot JVM 中的服务端垃圾收集器。G1使用【分代算法】, 将GC过程拆解为多个并发和并行阶段，将暂停时间打散，从而实现了低延迟特性，并保持良好的吞吐量。只要G1认为可以进行垃圾收集，就会触发一次GC, 当然，G1优先回收存活数据较少的区域。存活数据少就表示里面的垃圾对象多，这也是名字 Garbage.

1、对象无句柄在早期的JVM版本，例如 Classic VM 实现中，使用了 间接句柄(indirect handle) 来表示对象引用。虽然使用这种方式使得垃圾收集器在重定位对象（relocating）时非常方便，但却导致了严重的性能瓶颈，因为每次访问Java对象的实例变量都需要两步操作。HotSpot 推出以后，Java 代码就不再使用任何句柄。对象引用使用 直接指针(direct p...

更多的情况, 触发创建 native 线程时的OutOfMemoryError, 表明编程存在BUG. 比如, 程序创建了成千上万的线程, 很可能就是某些地方出大问题了 —— 没有几个程序可以 Hold 住上万个线程的。

Java平台限制了数组的最大长度。各个版本的具体限制可能稍有不同, 但范围都在 `1 ~ 21亿` 之间。如果程序抛出 `java.lang.OutOfMemoryError: Requested array size exceeds VM limit` 错误, 就说明想要创建的数组长度超过限制。

错误信息 java.lang.OutOfMemoryError: Out of swap space? 表明, 交换空间(swap space,虚拟内存) 不足,是由于物理内存和交换空间都不足所以导致内存分配失败。

一言不合就杀进程。。。我们知道, 操作系统(operating system)构建在进程(process)的基础上. 进程由内核作业(kernel jobs)进行调度和维护, 其中有一个内核作业称为 “Out of memory killer(OOM终结者)”, 与本节所讲的 OutOfMemoryError 有关。

本文通过实例介绍JDK7及之前的OutOfMemoryError: Permgen spaceJVM限制了Java程序的最大内存使用量, 可以通过启动参数来配置。各内存池的最大值, 由JVM启动参数 -Xmx 和 -XX:MaxPermSize 指定. 如果没有明确指定, 则根据操作系统平台和物理内存的大小来确定。

本文通过实例来分析 java.lang.OutOfMemoryError: Java heap space 问题产生的原因, 以及相关的解决方案

Java运行时环境内置了 垃圾收集(GC) 模块. 上一代的很多编程语言中并没有自动内存回收机制, 需要程序员手工编写代码来进行内存分配和释放, 以重复利用堆内存。在Java程序中, 只需要关心内存分配就行。如果某块内存不再使用, 垃圾收集(Garbage Collection) 模块会自动执行清理。GC的详细原理请参考 GC性能优化 系列文章, 一般来说, JVM内置的垃圾收集算法就能够应对绝大多数的业务场景。

G1垃圾收集器入门说明concurrent: 并发, 多个线程协同做同一件事情(有状态)parallel: 并行, 多个线程各做各的事情(互相间无共享状态)在GC领域: concurrent算法指GC线程和业务线程能并发执行； parallel指GC线程之间的并行。参考:What’s the difference between concurrency and paralle...

java.lang.OutOfMemoryError: Metaspace 错误所表达的信息是: 元数据区(Metaspace) 已被用满

RMI的垃圾回收算法为 引用计数法(reference-counting)

GC调优(Tuning Garbage Collection)和其他性能调优是同样的原理。初学者可能会被 200 多个 GC参数弄得一头雾水, 然后随便调整几个来试试结果,又或者修改几行代码来测试。其实只要参照下面的步骤，就能保证你的调优方向正确

首先, Dalvik虚拟机比其他Java虚拟机中的垃圾收集要简单一些, 因为没有进行内存整理(no compacting). 也就是说堆内存中的对象在创建之后其地址永远都不会发生改变, 使得虚拟机其余部分的实现变得相对简单。

**标记-清除**(Mark and Sweep)是最经典的垃圾收集算法。将理论用于生产实践时, 会有很多需要优化调整的地点, 以适应具体环境。下面通过一个简单的例子, 让我们一步步记录下来, 看看如何才能保证JVM能安全持续地分配对象。

顾名思义,垃圾收集(Garbage Collection)的意思就是 —— 找到垃圾并进行清理。但现有的垃圾收集实现却恰恰相反: 垃圾收集器跟踪所有正在使用的对象,并把其余部分当做垃圾。记住这一点以后, 我们再深入讲解内存自动回收的原理，探究 JVM 中垃圾收集的具体实现, 。我们不抠细节, 先从基础开始, 介绍垃圾收集的一般特征、核心概念以及实现算法。

用 jProfiler 分析 Java swing 程序中的内存泄漏问题时, 我发现内存中 JFrame 实例的数量一直在增加。各个 frame 被打开(opened),然后被关闭(closed)。通过 jProfiler, 并查看GC Root时, 只找到一项: 'JNI Global reference'。这是什么意思? 为什么他 hang 住了所有的 frame 实例?

学习了GC算法的相关概念之后, 我们将介绍在JVM中这些算法的具体实现。首先要记住的是, 大多数JVM都需要使用两种不同的GC算法 —— 一种用来清理年轻代, 另一种用来清理老年代。我们可以选择JVM内置的各种算法。如果不通过参数明确指定垃圾收集算法, 则会使用宿主平台的默认实现。本章会详细介绍各种算法的实现原理。

JVM上运行的程序多种多样, 启动参数也有上百个, 其中有很多会影响到 GC, 所以调优GC性能的方法也有很多种。还是那句话, 没有真正的银弹, 能满足所有的性能调优指标。 我们能做的只是介绍一些常见的/和不常见的示例, 让你在碰到类似问题时知道是怎么回事。深入理解GC的工作原理, 熟练应用各种工具, 就可以进行GC调优, 提高程序性能。

进行GC性能调优时, 需要明确了解, 当前的GC行为对系统和用户有多大的影响。有多种监控GC的工具和方法, 本章将逐一介绍常用的工具, 以及如何获取原生数据。 后续的章节将对重要的派生指标(derived metrics)展开讨论, 并引入GC性能相关的话题。

本文介绍GC日志的输出格式, 以及如何解读GC日志, 从中提取有用的信息。

本章简要介绍GC的基本原理和相关技术, 下一章节再详细讲解GC算法的具体实现。各种垃圾收集器的实现细节虽然并不相同,但总体而言,垃圾收集器都专注于两件事情: 1. 查找所有存活对象; 2.抛弃其他的部分,即死对象,不再使用的对象。相关术语翻译说明: Mark,标记; Sweep,清除; Compact,整理; Copy,复制;