JVM堆内存监测的一种方式，性能调优依旧任重道远

   <h3><strong>JVM堆内存及一种监测方式</strong></h3>    <p>在讨论Martijn的团队如何进行堆内存监测之前，我们先回顾下JVM的工作机制。JVM是一种对计算机的抽象行为，是它保证了Java程序的运行。每一个运行的Java程序都对应着一个JVM实例。JVM的结构如下图</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/5f349814004ae0843b5811a048f90372.png"></p>    <p>Java把内存划分成两种：一种是栈内存，一种是堆内存。栈与堆都是Java用来在RAM中存放数据的地方。与C++不同，Java自动管理栈和堆，程序员不能直接地设置栈或堆。堆内存用来存放由new创建的对象和数组。在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。即每一个Java应用都唯一对应一个JVM实例，每一个实例唯一对应一个堆。</p>    <p>自从Java1.3之后，Oracle出台的JRE就包含了一个名为HotSpot的JVM，它将Java的对象按照世代管理并存放在堆的内存中，以期可以更好地管理堆内存中的对象，包括内存的分配以及回收。共划分为三个世代：年轻代、老年代、永久代。永久代（Permanent Generation）则存放的是类的定义和相关元数据。但是在Java 8中该区域已经被移除。 </p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/04ed1876d6bb9d2e56ebc8e9c60230f6.png"></p>    <p>现有版本保留的两个世代为年轻代（Young Generation）和老年代（Old Generation）。年轻代为创建的短期对象，失效之后很快会被垃圾回收。该区又被划分为Eden和两个Survivor区域。老年代存放的多数为存活时间较长的对象。其中堆的各个区之间的比例分配有默认值，但是可以通过参数指定。垃圾回收GC分为两种Minor GC、Full GC；Minor GC发生频繁，但是仅针对年轻代。</p>    <p>垃圾回收之后会对JVM造成一定影响，年老代的占用空间曲线如下图：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/5c54d3a8d333ddf8bd9d0a15c4135292.png"></p>    <p>上图来自jClarity对堆的年老代占用空间监测图， <a href="/misc/goto?guid=4959716216696062319" rel="nofollow,noindex">jClarity是一款Java的性能监测工具</a> ，由Martijn、另外两位资深Java专家和一位机器学习工程师共同实现。Martijn分享了jClarity如何进行堆内存的监测他首先列举了垃圾回收之后，通常情况下堆内存中的老年代（Tenured/Old Generation）的内存占用曲线，一般而言，会先后发生两个陡然增加的高峰。</p>    <p>基于以上现象的信息， Martijn和他的团队开展了他们的性能监测方案。Martijn他们采取的做法是先收集尽可能多的点，然后只保留老年代的数据，对垃圾回收造成的两个脉冲式波峰进行了过滤，这时再对这些真正的数据点进行建模抽象，最后保留出了一条曲线。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/613d2a94fd8798266f1c1cae85b42425.jpg"></p>    <p>这条曲线就是对监测的Java程序内存的变化趋势，该曲线会以50Mb/小时的速率增长，据此推测出何时发生内存泄露。jClarity还有很多其他功能，相比于传统的指标统计方式，Martijn称团队产品的特点在于：高级统计+机器学习。</p>    <h3><strong>Java和JVM面临怎样的困境？</strong></h3>    <p>Martijn还分享了他对Java现状和JVM性能调优的担忧和思考，他认为现在Java和JVM面临下面五个问题：</p>    <ol>     <li>程序只能写一次，但是却要在各种地方跑<br> 这意味着Java需要解决来自各方面的差异：<br> CPU的差异——什么时候可以放入缓存中呢？什么时候可以被重新排序呢？<br> 文件系统的差异——不同操作系统对文件的符号链接有不同机制<br> 显示设备的差异——硬件更新速度很快，几乎无法追上<br> 原生库支持的差异——很难存在所有的原生库皆一致的情况<br> 操作系统线程管理的差异——线程的规划方式很不相同<br> 此外，面对正在迅速发展AR、VR，Java缺少真正的GPU支持，这同样是一个短板。</li>     <li>模型对存储的强需求<br> JVM太谨慎了，他总想做对的事情，但是为此不得不在性能上的妥协。锁机制加强了正确性，但是在性能上付出了巨大的代价。<br> 锁机制决定了Java序列化的工作区。因为Java对象序列化不仅保留一个对象的数据，而且递归保存对象引用的每个对象的数据。可以将整个对象层次写入字节流中，可以保存在文件中或在网络连接上传递。利用对象序列化可以进行对象的"深复制"，即复制对象本身及引用的对象本身。序列化一个对象可能得到整个对象序列。结合利特尔法则（Little's law）和阿姆达尔定律（Amdahl’s law），这种方式影响到了并行存储的性能。</li>     <li>垃圾回收机制下的扩展性<br> JVM需要维护活的对象，这意味着：堆需要更大空间以存放更多的对象；垃圾回收机制需要花时间去辨认哪些是活的对象；在垃圾回收过程中需要耗费时间进行堆的维护。<br> 其次，Java中没有值类型（value type 和reference type的区别），没有结构体：这造成了大量低效能的对象创建。</li>     <li>容器和虚拟化的支持<br> Java没法获取虚拟化数据。Java和JVM的思考模式是建立在物理裸机上的，信息缺失的情况下会进行一些错误选择。并且，没有对Docker等容器技术的直接支持，这是新时代的另一个短板。</li>    </ol>    <h3><strong>关于Java和JVM性能调优的思考</strong></h3>    <p>除了上述的整体层面的挑战之外，Java的性能本身又很难监测。必须结合其他的指标来间接把控：CPU，内存；接口/O，网络I/O；虚拟化和容器化等。可是一旦获得了这些指标，又带来了大数据的问题。因为我们盲目地收集了过多的数据，这造成了巨大的性能损害，因为收集、传输、存储每个过程都是一种消耗。</p>    <p>要记住目的是分析获得信息，而不是收集指标。但是从指标数据到提炼出有用信息很难，Martijn认为要做好性能调优需要明白规律和原理（如上文所提及的Little's law和Amdahl’s law），理解硬件、操作系统、Java工作原理还要读懂代码，并且已经有了基于大量数据的分析经验。</p>    <p>Martijn认为未来性能监测的趋势是高级统计和机器学习方式的结合，这种模式将取代传统的单纯指标采集模式。</p>    <p><strong>对话Martijn</strong></p>    <p><strong>InfoQ：通常来说，JVM层面的APM工具并不适用于生产环境。那为什么您称jClarity可以？</strong></p>    <p>Martijn：与其他工具相比，首先在JVM层面上我们获取更少的数据。 jClarity之所以可以更少地获取，是因为我们采用了机器学习的办法，辨别除了哪些才是真正有用的数据，我们称之为“信号”，余下的数据我们称之为噪声。在收集数据过程中，一旦检测噪声，我们立刻对过滤。</p>    <p>其次我们还会尽可能避免从JVM本身获取数据，取而代之从JVM的日志中（如GC日志、safepoint日志）等获取数据。目前我们还在和Google合作，在尝试怎样从JVM之外，获得更多的信息。但是，总体而言，jClarity用于生产环境是没有问题的。</p>    <p><strong>InfoQ：为什么还要收集JMV的日志之外的数据呢？</strong></p>    <p>Martijn：因为JVM日志并不能给我们足够的信息。你可以从JVM日志中获得，或者通过JMX接口。不过，你也可以通过设定一个Java或者原生的agent来获得更特定的信息；但这是一种过重的做法，通常而言并不推荐。很多人包括Oracle在内都意识到了这个问题，但是完全解决有待时日。</p>    <p><strong>InfoQ：数据收集的过程是否对用户来说是透明的呢？是否支持ASM字节码织入技术呢？</strong></p>    <p>Martijn：是的。底层的数据，我们不仅仅从Java中获得，还会从操作系统中获取。比如，当用户在Linux上运行，那么他还会看见收集到的CPU、内存使用率等信息。</p>    <p>对于有特殊需求的用户，他们是可以采用ASM，此外我们也提供一个开发阶段使用的库，但是建议用户小心使用，因为很容易会产生操作不当。</p>    <p><strong>InfoQ：数据收集之后，jClarity根据机器学习出来的成果进行了处理，能否和我们分享下机器学习的事情？</strong></p>    <p>Martijn：在我被许可的范围内，因为机器学习是我们的机密模块。不过我可以分享这里非常重要的一点：我们有大量多环境的用户数据，用户们的程序也是多种多样，如网页程序、视频流程序等；我们会施加不同的网络压力，这样我们得到了数据训练集。这些数据集是专家人工操作产生的。同时在实时收集处理数据的时候，我们也会进行机器学习。比如发现Java性能受到影响，机器学习认定最重要一个因素就是GC垃圾回收，那么接下来就是调查GC；如果GC没有问题，那么就会在机器学习成果的指引下开始下一个因素的勘察。总体而言，机器学习的决定了发生问题时排查的路径。</p>    <p>机器学习这部分的研发工作我们做了两年，也很感谢这些用户为我们付费并且同意我们这样做。我们的一些用户拥有超大规模，这种情况下，已经无法指望人工对数据进行分析；所以对于我们来说，机器学习是唯一的出路，唯一的方式可以让我们继续支持用户。</p>    <p><strong>InfoQ：APM工具的挑战有哪些？</strong></p>    <p>Martijn：首先是IT环境复杂性的加剧。你的代码不再跑在你自己的机器和环境中，你无法做到100%确定你的程序和代码是怎样被管理的。另外一个挑战就是网络是不稳定的。在有线光纤专用网络上，你不需要和其他人共享；但是在公用云上，网路流量徒增的情况时有发生，开发人员不得不在代码层面上面对这个挑战，APM工具也必须理解并迎面这个问题。目前，还没有哪个APM工具可以胜任这两个挑战，所以目前这还是一个非常有趣有待研究的领域。</p>    <p><strong>InfoQ：您在演讲中有提到，Java创立之初硬件并没有今天这样复杂，那么是不是说Java已经不再适合今天了呢？你认为Java语言的独特魅力在哪里呢？</strong></p>    <p>Martijn：“Java将死”的留言每年都有。Java语言这么多年，经常遇到新兴语言的挑战，但是新兴语言很快就会发现自己也处于一个类似的局面。我认为Java依然是一个合适的语言，JVM正在尝试在各种情况下都做到最好。我们可以看到Go、RUST语言变得越来越火，但是Oracle正在非常努力地攻克这点，包括更频繁地发布Java，也很想快速地跟上包括支持GPU、其他新型硬件设备等。所以说挑战是有的，但是令人高兴的是很多大公司都愿意继续努力提高Java。我希望Java社区可以更开放些，可以欢迎更多的公司参与，比如阿里巴巴，阿里巴巴可能是全球上最大的重度Java研发群。</p>    <p>Java的魅力在于易写性、强可读性。不像现在的一些语言，你不需要严格地按照某种规范来写代码。就算代码写完五年之后，新来的人依然可以读懂代码。还有就是Java丰富的框架和库。甚至这些框架和库的魅力可以和Java语言本身相媲美。</p>    <p> </p>    <p> </p>    <p>来自：http://www.infoq.com/cn/news/2016/09/APM-jClarity-jvm-heap-oldgen</p>    <p> </p>