<% for (Map.Entry
7、HSIDS：JIT生成代码反汇编
HSIDS是一个Sun官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件
二、JDK的可视化工具
1、JConsole：java监视与管理控制台
JConsole（java monitoring and management console）是一种基于JMX的可视化监视管理工具，它管理部分的功能是针对JMX MBean进行管理，MBean可以使用代码，中间件服务器的管理控制台或者符合JMX规范的软件进行访问。
2、VisualVM：多合一故障处理工具
VisualVM（All-in-One java Troubleshooting Tool）是到目前为止随JDK发布的功能最强大的运行监视和故障处理程序，并且可以预见在未来一段时间内都是官方主力发展的虚拟机故障处理工具，官方在VisualVM的软件说明上写上了“All-in-One”的描述字样，预示着它除了运行监视、故障处理外，还提供了很多其他方面的功能，如性能分析，VisualVM的性能分析功能甚至比起JProfiler YourKit等专业且收费的Profiling工具都不会逊色多少，并且VisualVM还有一个很大的优点：不需要被监视的程序基于特殊Agent运行，因此它对应用程序的实际性能的影响很小，使得它可以直接应用在生产环境中，这个优点是JProfiler YourKit等工具无法与之媲美的。
第五章 调优案例分析与实战
=================
在《深入理解java虚拟机》书中本节的主要内容是讲作者在工作过程中对调优的一些经验实战。对于我们读者来说，重点是学习作者分析解决问题的具体思路。
一、编译时间和类加载时间的优化
编译时间是指虚拟机的JTI编译器编译热点代码的耗时。
虚拟机内置了两个运行时编译器，如果java方法被调用次数达到一定程序，就会被判定为热代码交给JIT编译器，即时编译为本地代码，提高运行速度，这就是Hotspot虚拟机名字的由来。
二、高性能硬件上的程序部署策略
1、基本信息简介
（1）环境：一个15万PV/天左右的在线文档类型网站最近更换了硬件系统，新系统硬件为4个CPU、16G物理内存、OS为64位CentOS5.4、Resin作为Web服务器。
（2）说明：整个服务器暂时没有部署别的应用，所有硬件资源都可以提供给访问量并不算太大的网站使用。管理员为了尽量利用硬件资源选用了64位的JDK1.5，并通过-Xms和-Xms参数将java堆固定在12GB。
（3）问题：使用一段时间后发现使用效果不理想，网站经常不定期出现长时间没有响应的现象。
（4）排查：监控服务器运行状况后发现网站没有响应是由于GC停顿导致的，虚拟机运行在Server模式中，默认使用吞吐量优先收集器，回收12GB的堆，一次Full GC的停顿时间高达15秒。并且由于程序设计的关系，访问文档时要把文档从磁盘提取到内存中，导致内存中出现很多由文档序列化产生的大对象，这些大对象很多都进入了老年代，没有在Minor GC中清理掉。这种情况下即使有12GB的堆，内存也很快被消耗殆尽，由此导致每隔十几分钟出现十几秒的停顿。
（5）分析：先不延伸讨论程序代码的问题，程序部署上主要问题显然是过大的堆内存进行回收时带来的长时间停顿。硬件升级前使用32位系统1.5GB的堆，用户只感受到访问网站比较缓慢，但不会发生十分明显的停顿，因此才考虑升级硬件来提升程序效能，如果重新缩小给java堆的内存，那么硬件上的投资就浪费了。
2、高性能硬件上部署程序的方式
目前主要有两种方式：
（1）通过64位JDK来使用大内存
（2）使用若干个32位虚拟机建立逻辑集群来利用硬件资源
3、通过64位JDK来使用大内存
对于用户交互性强、对停顿时间敏感的系统，可以给java虚拟机分配超过堆的前提是有把握把应用程序的Full GC频率控制得足够低，至少要低到不会影响用户使用，譬如十几个小时乃至一天才出现一次Full GC，这样可以通过在深夜执行定时任务的方式出发Full GC甚至自动重启服务器来将内存可用空间保持在一个稳定的水平。
控制Full GC频率的关键是看应用中绝对多数对象能否符合“朝生夕灭”的原则，即大多数对象的生存时间不应太长，尤其是不能产生批量的、长生存时间的大对象，这样才能保证老年代空间的稳定。
在大多数网站形成的应用里，主要对象的生存周期都应该是请求级或页面级的，会话级和全局级的长生命对象相对减少。只要代码写的合理，应当都能实现在超大堆中正常使用而没有Full GC，这样的话，使用超大堆内存时，网站响应的速度才比较有保证。除此之外，如果读者计划使用64位JDK来管理大内存，还需要考虑下面面临的问题：
（1）内存回收导致的长时间停顿
（2）现阶段，64位JDK的性能测试结果普遍低于32位JDK
（3）需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎无法产生堆转储快照（因为要产生十几GB乃至更大的dump文
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
件），哪怕产生了快照也几乎无法进行解析。
（4）相同的程序在64位JDK中消耗的内存一般比32位JDK大，这是由于指针膨胀及数据型对其补白等因素导致的。
4、使用若干个32位虚拟机建立逻辑集群来利用硬件资源
具体做法是在一台物理机器上启动多个应用服务器进程，给每个服务器进行分配不同的端口，然后再前端搭建一个负载均衡器，以反向代理的方式来分配访问请求。读者不需要太在意均衡器转发所消耗的性能，即使使用64位JDK，许多应用也不止有一台服务器，因此许多应用中前段的均衡器总是要存在的。
考虑到一台物理机上建立逻辑集群的目的仅仅是尽可能的利用硬件资源，并不需要关心状态保留、热转移之类的高可用性需求，也不需要保证每个虚拟机进程有绝对准确的均衡负载，因此使用无session复制的亲和式集群是一个相当不错的选择。我们仅仅需要保证集群具有亲和性，也就是均衡器按一定的规则算法将一个固定的用户请求永远分配到固定的一个集群节点进行处理即可，这样程序开发阶段就基本不用为集群环境做什么特别的考虑。