jvm内存JVM学习笔记-引用(Reference)机制

在写这篇文章之前，xxx已经写过了几篇关于改jvm内存主题的文章,想要了解的朋友可以去翻一下之前的文章

如果你还不了解JVM的基本概念和内存划分，请阅读JVM学习笔记-基础知识和JVM学习笔记-内存处理文章。

因为Java中没有留给开发者直接与内存打交道的指针（C++指针），所以如何回收不再应用的对象问题，就丢给了JVM。所以接下来就介绍一下目前主流的垃圾收集器所采取的算法。不过在此之前，有须要先了解Reference

1.引用（Reference）

如果你当初还是JDK1.0或者1.1版本的开发者？可以跳过以下部分内容；如果不是的话，上面这些内容还是有参考价值的。你可能会问，Reference还有什么可讲的？还是有一点，你知道Reference有四中分类吗？这可不是孔乙己的四种“回”字写法可以类比的。讲到引用（Reference），我们最先想到的一般是：

Object obj = new Object();

这种属于Strong Reference（JDK1.2之后引入），这类Reference的特点就是，只要Reference还在，目标对象就不能被干失落。我们可以想一下为什么要干失落一些对象？很简单，因为内存不够了。如果内存狗应用，大家都或者就好了。所以当内存不都时，会先干失落一些“必逝世无疑的家伙”（上面会解释），如果这时候内存还不够用，就干失落那些“可逝世可不逝世的家伙”了。

JDK1.2之后还引入了SoftReference和WeakReference，前者就是那些“可逝世可不逝世的家伙”。当进行了一次内存清算（干失落“必逝世无疑”的家伙）后，还不够用，就再进行一次清算，此次清算的内容就是SoftReference了。如果干失落Soft Reference后还是不够用，JVM就跑出OOM异常了。

    每日一道理
风，渐渐吹起，吹乱了我的发丝，也让我的长裙有些飘动。绿叶仿佛在风中起舞，离开了树，投向了大地，却不知这样会枯萎，我弯下腰，轻轻拾起一片树叶，那非常有序的茎脉，是一种美的点缀。我有些哀叹：绿叶啊，绿叶，你这般美丽地从树上轻轻飘下，随风起舞，却不知已被人称之为落叶！

似乎WeakReference还没说呢？它是干吗的？其实就是那些“必逝世无疑的家伙”。每一次JVM进行清算时，都会将这类Reference干失落。所以一个WeakReference出身后，它的逝世期就是下一次JVM的清算。

“回”字的最后一种写法，是PhantomReference，名字很恐惧吧（Phantom是幽灵的意思）。这类Reference的唯一作用，就是当响应的Object被Clean失落的时候，通知JVM。

虽然有四中“回”字，但是Strong Reference却没有响应的类，java.lang.ref.Reference只有三个子类。

你可能会发明，在Reference这一部分，经常性的提到“清算”。什么“清算”？就是上面要说的 Garbage Collection中对“无用”对象的clean。

这是JVM的核心功能之一，同时也是为什么绝大多数Java工程师不需要像C++程序员那样考虑对象的生存周期问题。至于因此而同时致使Java工程师不能够放任自由地控制内存的结果，实际上是一个Freedom与Effeciency 之间的trade-off，而C++工程师与Java工程师恰如生存在两个适度的人，似乎“幸福生活”的天朝人民与“水生炽热”的东方庶民之间的“时而嘲笑、时而艳羡”一般。

言归正传，Garbage Collector（GC ）是JVM中筛选并清算Garbage的工具。那么第一个要搞清楚的问题是，什么是Garbage？严谨的说，Garbage就是不再被应用、或者以为不再被应用、甚至是某些情况下选作“牺牲品”的对象。看上去很啰嗦，那就先懂得成“不再被应用”吧。这就出现了第二个问题，怎么判断不再被应用？这就是后面将介绍的对象标记算法（Object Marking Algorithms）

文章结束给大家分享下程序员的一些笑话语录：

自行车
一个程序员骑着一个很漂亮的自行车到了公司，另一个程序员看到了他，问 到，“你是从哪搞到的这么漂亮的车的？”
骑车的那个程序员说， “我刚从那边过来， 有一个漂亮的姑娘骑着这个车过来， 并停在我跟前，把衣服全脱了，然后对我说，‘你想要什么都可以’”。
另一个程序员马上说到， “你绝对做了一个正确的选择， 因为那姑娘的衣服你 并不一定穿得了”。

---------------------------------
原创文章 By
jvm和内存
---------------------------------