点滴记录

在进入主题之前，我们要先知道运行时数据区域都是有哪些块内存需要进行垃圾回收。     程序计数器、虚拟机栈、本地方法栈、3个区域都是随着线程生而生，随着线程灭而灭的；栈中的栈帧随着方法的进入和退出有条不紊的执行着进栈和出栈的操作。每一个栈帧中分配多大的内存基基本上在类结构确定下来后就已知了，因此这几个区域的内存分配和回收都具备确定性，在这几个区域就不需要过多的考虑垃圾回收的问题，因为 方法结束或者

转载请注明出处：http://blog.youkuaiyun.com/ns_code/article/details/17675609 平台无关性    Java是与平台无关的语言，这得益于Java源代码编译后生成的存储字节码的文件，即Class文件，以及Java虚拟机的实现。不仅使用Java编译器可以把Java代码编译成存储字节码的Class文件，使用JRuby等其他语言的编译器也可以把程序代码编译成C

运行时数据区域    Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域都有各自的用途，以及创建和销毁时间。以下是Java虚拟机所管理的内存区域： 程序计数器    程序计数器(Program Counter Register)是一块较小的内存空间，它可以看作时当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里，字节码解释器工作时就是通过改变这个计

Java堆的唯一目的就是创建实例对象，几乎所有的对象都在堆上分配内存，如果堆空间分配内存出现问题可见是非常严重的。当Java 堆内存出现问题时，我们应该怎么去优化呢？在学习堆内存优化之前，我们要先了解一下有关堆内存优化的参数。堆在实现时，既可以实现成固定大小的，也可以是可扩展的，当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。     在这里通过程序测试一下：public c

在经过了几次跳票之后，Java 9终于在原计划日期的整整一年之后发布了正式版。Java 9引入了很多新的特性，除了闪瞎眼的Module System和REPL，最重要的变化我认为是默认GC（Garbage Collector）修改为新一代更复杂、更全面、性能更好的G1（Garbage-First）。JDK的维护者在GC选择上一直是比较保守的，G1从JDK 1.6时代就开始进入开发者的视野，直到今天

在Java程序运行的过程中无时无刻都有对象被创建。在程序中创建对象(克隆，反序列化)通常是一个new 关键字而已，下面将在虚拟机的角度看待对象是如何被创建出来的。Java对象创建的过程    1. 虚拟机遇到一条new 指令时，首先将会检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并检查这个符号引用代表的类是否被加载，解析和初始化过。如果没有那就先执行相应的类加载过程。    2. 在类

垃圾收集器与内存分配策略参考目录： 1.判断Java 对象实例是否死亡 2. Java 中的四种引用 3.垃圾收集算法 4. Java9中的GC 调优 5.内存分配与回收策略对象优先在Eden 分配       在大多数的情况下，对象在新生代Eden 区中分配内存空间。当Eden 区没有足够的空间进行分配时，这时虚拟机将执行一次Minor GC，由于Eden 区没有足

这篇博文主要介绍虚拟机中的几种垃圾回收算法(当然进行垃圾回收的地方主要是指Java 堆)。标记 - 清除算法(Mark-Sweep)      标记清除算法也是最基础的算法，和它的名字一样，在进行垃圾回收的时候主要分为“标记阶段” 和“清除阶段” ： 首先标记出所需要回收的对象，在标记完成后进行统一回收所有被标记的对象。其他后面的几种算法都是在它的基础上对它做出的改进。标记清除算法在效率是上存在着一

在进行垃圾回收之前，虚拟机判定对象是否需要回收都与”引用”相关。在jdk1.2 之前，Java 关于引用的定义很传统：如果reference 类型的数据存储的数值代表另一块内存的起始地址，就称这块内存代表着一个 引用。这种定义看似很纯粹，但是却是很狭隘的，因为一个对象被定义出来只有被引用或者没有被引用两种状态。我们希望能这样描述一类对象：当内存空间还足够时，则保留在内存中；如果内存在进行垃圾回收之后

(一)类加载时机类生命周期的七个阶段类从被加载进虚拟内存开始，到卸载出内存为止，整个生命周期包括：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中验证、准备和解析3个阶段统称为连接(Linking)，这7个阶段发生的顺序