jmap - Java 内存映像工具

0

jmap(Memory Map for Java) 命令用于生成堆转储快照(一般称为 heapdump 或 dump 文件)。目前获取 Java 堆转储快照的方式有以下几种:

jps - 虚拟机进程状况工具

0

jps(JVM Process Status Tool)与 UNIX 的 ps 命令类似:可以列出正在运行的虚拟机进程,并显示虚拟机执行主类(Main Class,main()函数所在的类)名称以及这些进程的本地虚拟机唯一 ID(Local Virtual Machine Identifier,LVMID)。虽然功能比较单一,但它是使用频率最高的 JDK 命令行工具,因为其他的 JDK 工具大多需要输入它查询到的 LVMID 来确定要监控的是哪一个虚拟机进程。对于本地虚拟机进程来说,LVMID 与操作系统的进程 ID(Process Identifier,PID)是一致的,使用 Windows 的任务管理器或者 UNIX 的 ps 命令也可以查询到虚拟机进程的 LVMID ,但如果同时启动了多个虚拟机进程,无法根据进程名称定位时,那就只能依赖 jps 命令显示主类的功能才能区分了。

jvm 内存溢出 - 方法栈溢出

0

Java 程序中堆栈( Stack Space )用来做方法的递归调用时压入栈帧( Stack Frame ),每个线程都有自己的堆栈,这个堆栈不是来自 Heap 的分配。所以堆栈的大小不会受到 -Xmx-Xms 的影响,这2个 JVM 参数仅仅是影响 Heap 的大小。虚拟机参数 -Xss 用来指定每个线程的堆栈大小,设定该值后,当递归调用太深的时候,就有可能耗尽堆栈空间,爆出 StackOverflow 的错误,我们使用如下代码做实验:

Java 对象的内存分配策略

0

本文主要通过几个简单的例子介绍 Java 对象的内存分配策略。

Java 垃圾回收 - 垃圾回收算法

0

本文主要介绍几种常用的垃圾回收算法:标记 - 清除算法、复制算法、标记 - 整理算法、分代收集算法。

Java 垃圾回收 - 如何判断对象已死

0

关于 Java 的垃圾收集( Garbage Collection,GC ),Java 运行时区域的各个部分,程序计数器、虚拟机栈、本地方法栈 3 个区域随线程而生,随线程而灭;栈中的栈帧随着方法的进入和退出而有条不絮的执行者岀栈和入栈操作。
每个栈帧中分配多少内存基本上实在类结构确定下来时就已知的,因此在这几个区域内存的分配和回收都具有确定性,就不需要过多考虑回收的问题,因为在方法结束或者线程结束时,内存就自然跟着回收了。既然 Java 的内存回收已经如此智能,我们为什么还有继续了解 GC 和内存分配呢?

Java 垃圾回收 - 使用 finalize 方法拯救自己

0

在可达性分析算法中不可达的对象,也并非是“非死不可”的,一个对象死亡,至少要经历两次标记过程:如果对象在进行可达性分析后发现没有与 GC Roots 相连接的引用链,那它将会被第一次标记并且进行一次筛选,筛选的条件是此对象是否有必要执行 finalize ( ) 方法。当对象没有覆盖 finalize ( ) 方法,或者 finalize ( ) 方法已经被虚拟机调用过,虚拟机将这两种情况都视为“没有必要执行”。

Centos7 下编译 Openjdk8

0

本文主要介绍如何在 Centos7 下编译 Openjdk8 源码,《深入理解java虚拟机》第二版网上好多 openjdk7 的帖子,编译 jdk8 和 7 还是有些差别的,比如大家经常提到的 make sanity 在 jdk8 源码里是没有的,下面我们一步步编译 openjdk8。

Java 垃圾回收 - 方法区回收

0

很多人认为方法区(或者 HotSpot 虚拟机中的永久代)是没有垃圾收集的,Java虚拟机规范中确实说过可以不要求虚拟机在方法区实现垃圾收集,而且在方法区中进行垃圾收集的“性价比”一般比较低:在堆中,尤其是在新生代中,常规应用进行一次垃圾收集一般可以回收 70%~95% 的空间,而永久代的垃圾收集效率远低于此。

Java 垃圾回收 - 垃圾收集器

0

Java 虚拟机规范中对垃圾收集器应该如何实现并没有任何规定,因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别,并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。下面是 JDK 1.7 Update 14之后的 HotSpot 虚拟机包含的所有收集器: