blog

调优案例分析

JVM

大内存硬件上的程序部署策略一个15万PV/日左右的在线文档类型网站最近更换了硬件系统，服务器的硬件为四路志强处理器、16GB物理内存，操作系统为64位 CentOS 5.4，Resin作为Web服务器。整个服务器暂时没有部署别的应用

JVM

jps：虚拟机进程状况工具可以列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class，main()函数所在的类）名称以及这些进程的本地虚拟机唯一 ID（LVMID，Local Virtual Machine Ident

JVM

对象优先在Eden分配 HotSpot虚拟机提供了-XX：+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况。

JVM

虚拟机及垃圾收集器日志阅读分析虚拟机和垃圾收集器的日志是处理Java虚拟机内存问题必备的基础技能，垃圾收集器日志是一系列人为设定的规则，多少有点随开发者编码时的心情而定，没有任何的“业界标准”可言，换句话说，每个收集器的日志格式都可能不一样。除此以外还有一个麻烦，在JDK 9以前，HotSpo

JVM

ZGC介绍 ZGC（The Z Garbage Collector）是JDK 11中推出的一款追求极致低延迟的实验性质的垃圾收集器，它曾经设计目标包括：停顿时间不超过10ms；停顿时间不会随着堆的大小，或者活跃对象的大小而增加；支持8MB~4TB级别的堆，未来支持16TB。基于最新的JDK1

JVM

衡量垃圾收集器的三项最重要的指标是：内存占用（Footprint）、吞吐量（Throughput）和延迟（Latency），三者共同构成了一个“不可能三角[1]”。三者总体的表现会随技术进步而越来越好，但是

JVM

Serial收集器 Serial收集器是最基础、历史最悠久的收集器,是一个单线程工作的收集器，迄今为止，它依然是HotSpot虚拟机运行在客户端模式下的默认新生代收集器，有着优于其他收集器的地方，那就是简单而高效（与其他收集器的单线程相比），对于内

JVM

什么是OopMap 由于目前几乎所有虚拟机都是用可达性分析算法来判定对象是否存活，即通过选定固定的gc roots作为起始节点，像剥洋葱一样往下溜达，只要存在任意节点从gc roots到该节点不可达，那表示这个对象不被任何对象所引用，这个对象最终就要被当做垃圾回收掉。问题来了，如何找到这些gc r

JVM

如果移动存活对象，尤其是在老年代这种每次回收都有大量对象存活区域，移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作，而且这种对象移动操作必须全程暂停用户应用程序才能进行[1]，这就更加让使用者不得不小心翼翼地权衡其弊端了，像这样的停顿被最初的虚拟机</

JVM

程序计数器、虚拟机栈、本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由即时编译器进行一些优化，但在基于概念模型的讨论里，大体上可以认为是编译期可知的），因此这几