java内存管理 美好的期望与现实的残酷

美好的期望—看山是山，看水是水

犹记得当年刚入门学Java课时；99%的java基础性书籍和带领入门的老师都会介绍java的一项优点；即：Java 语言不使用指针，它加入了垃圾回收机制，解决了程序员需要管理内存的问题，使编程变得更加简单。

刚开始接触这段话时，心理感觉java语言太优秀了，尤其是在大一学过C语言的指针而被它搅的东南西北都摸不到方向后；自然而然的认可 java是一门懂程序员的语言：在编写业务代码实现业务功能的时候，还要花掉大部分的脑细胞来管理内存，想想就头大。可以用一句当年在编程界争论了无数次，日后很有可能还会引起无数programmer 争论的：“XXX是世界上最好的编程语言” 来代表当时内心的激动和对他的期望。

闯入迷雾—看山不是山，看水不是水

别了校园，入了江湖。亲身经历了多个java实战项目后；让我对之前java 内存管理和回收机制产生了疑惑：
这种疑惑来自于多个java项目在上线后，或多或少都有点内存问题，从而引发jvm GC频繁执行，导致后端接口的TPS急剧下降，并且响应时间陡峭的上升。
内存不是由jvm 管理吗？jvm 有垃圾回收机制，那么执行了垃圾回收后，为什么内存还不能释放了？

走出困境—看山还是山，看水还是水

也是经过系统学习和个人总结，外加实战后，才貌似明白最初看到的那句话。java 语言确实提供了垃圾回收机制，并且管理了内存。但如果使用的姿势有问题，仍然会有内存泄漏问题，并且还会引起jvm的垃圾回收机制失效，内存无法回收。具体如何失效或者错误的使用，可以另外写一篇反例 《让jvm宕机的n种编程习惯》这里就暂不展开了。

完全颠覆—看出了另外一片天空

再后来解读kafka生产端源码和netty框架时，完全颠覆了对这句话的理解。java有内存管理，但是这些优秀的高手们不用，他们要在java语言里，用java代码来管理java内存（很有点用自身的魔法来打败自身的味道）。原因就在于 这些优秀的三方框架或者中间件，为了追求极致的性能，又或者为了避免上层应用因使用自身功能带来的内存和性能而引发的业务问题。

他们认为jvm的GC过程是个重型操作，费时又费力，还会引起stop the word，在STW这段时期上层业务是临时中断的，而这种频繁的临时性中断 汇聚起来后，对业务是巨大的伤害和阻碍；而减少JVM的STW的时间和减少对业务的影响，也是Java GC优化大师现在和未来的目标之一，从PS，CMS，G1，ZGC都在往这个目标上努力。

总结

在对java内存管理的看法上，又回到了起点；如果用一句话来表达这种转变。我想借用
《深入理解java虚拟机》的作者周志明老师的总结：在java和C++程序员之间有一堵内存的墙；墙外的人想进去；墙内的人想出来

原创不易，请 点赞，关注，留言，转载 4暴击^^