client 与 server
Created|Updated|Java
|Word Count:168|Reading Time:1mins|Post Views:
client 模式
默认的jit编译器,c1。
默认的gc:serial-serial old。
需要更短的启动时间和初始堆大小,能做更保守的优化。
默认-Xms是1M,-Xmx是64M。
适合 GUI 程序。
server 模式
默认的jit编译器,c2。
默认的gc:ps-serial old即 PS MarkSweep(可以启用parallel old)。
需要更长的启动时间和更大的堆大小,能够做更有深度的优化。
默认-Xms是128M,-Xmx是1024M。
适合长时间运转的程序。
64 位JVM#
在64位 JVM 上有个 -d64 的模式,实际上就是禁止client模式单独启动,只允许server模式或者混合编译模式启动的模式。
Author: magicliang
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2022-01-12
Java中的条件编译
一个流传已久的传说 在中文 Java 圈子里有这样一段传说:Google(或某家硅谷大厂)有一种「Java 条件编译」技术,可以在同一份源码里写「测试开关打开时才走的代码」,非生产流水线编译时整段代码都在,可以照常调试;上了生产、关掉开关,被 if 包围的那段 Java 代码就会被编译器当成死代码,从字节码里直接抹掉,线上绝对跑不到。 这段传说混杂了三个独立的问题: Java 是否真的存在「if 块在生产编译时从字节码消失」这种机制? 这是 Google 独有的私货,还是标准 Java 的能力? 如果代码真的被编译器去除,那调试还能怎么做? 回答它们需要三种证据:JLS §14.21、§13.4.9、§15.28 的规范条文给出语言契约;一组可复现的 javap 字节码实验给出实证;feature switch 工业谱系(javac 死代码消除、BuildConfig.DEBUG + R8、Manifold 预处理器、AspectJ 类加载织入、OpenFeature 运行时开关、HotSpot C2 运行时死分支折叠)给出工程参照系。 文中代码示例基准 Java 8,字节...
2017-10-27
基于栈的虚拟机
基于栈的虚拟机 全景导图 mindmap root((基于栈的虚拟机)) 核心架构 操作数栈 局部变量表 栈帧 执行机制 字节码指令 基于栈的运算 指令集简洁性 设计优势 可移植性 代码紧凑 实现简单 典型应用 JVM Python虚拟机 .NET CLR 模式总览 # 模式名称 一句话口诀 覆盖场景 1 栈式计算 数据流与控制流分离,操作数隐式传递 JVM字节码执行、表达式求值、递归调用 2 栈帧隔离 每个方法调用独立的执行上下文 方法调用、异常处理、线程隔离 3 指令紧凑 操作数位置编码在指令中,减少指令长度 字节码压缩、跨平台分发 问题定义 为什么选择基于栈的虚拟机架构,而非基于寄存器的架构?这种设计如何影响字节码的生成、执行效率以及跨平台可移植性? 核心概念 虚拟机架构分类 虚拟机按照指令集架构主要分为两类: 基于栈的虚拟机:指令不指定操作数的位置,操作数从栈顶弹出...
2026-04-19
Java栈帧省略机制详解:为什么异常堆栈会消失?
引言:诡异的异常堆栈消失现象 线上服务报错时,你打开日志准备排查问题,却发现异常堆栈信息神秘消失了: 1java.lang.NullPointerException 只有短短一行异常类名,没有完整的堆栈跟踪。你可能会怀疑:是日志框架出问题了?还是被什么拦截器截断了? 其实,这是 JVM 的一个性能优化机制,叫做 OmitStackTraceInFastThrow(快速抛出时省略堆栈跟踪)。从 JDK 5 开始引入,默认启用。 本文将深入剖析这个机制的设计动机、工作原理、触发条件,以及如何正确应对。 一、问题场景:异常堆栈去哪了? 1.1 复现现象 用一段简单的代码就能复现: 123456789101112public class ExceptionOmitDemo { public static void main(String[] args) { String msg = null; for (int i = 0; i < 500000; i++) { try { ...
2021-10-09
JDK 的广泛分支
Oracle Hospot JDK java 8 特定版本以后就不再免费了。 现有的JDK8,2019.1之前的更新都可以免费获取正常使用。 Oracle JDK11是一个长期支持的版本,用于商业环境需要付费。 Azul Zulu builds of OpenJDK Zulu 是Azul公司基于OpenJDK发布的Java SE产品,它没有Oracle JDK对使用场景上的诸多限制,可以放心免费下载和使用。它的核心部分就是原汁原味的OpenJDK,没有任何额外的改动——Azul有时候也会对OpenJDK做bug fix,但这些都是通过提交回到OpenJDK去然后再进入到Zulu Java SE产品中的。它与“自己下载OpenJDK源码,自己build”的最大区别是:Azul会在每次发布Zulu产品之前进行充分的测试,build出来的二进制版本符合Java的兼容性测试;同时,Azul有与Oracle签订合作协议,在critical security fix的方面会比公开发布的OpenJDK源码要更早获得补丁,提前做好build与测试工作,基本上可以跟Oracle在同一时...

2018-10-13
卡表和 RSet
卡表和 RSet 问题定义:为什么需要跨区域引用记录 JVM 垃圾收集器的核心工作之一是确定 live set——哪些对象仍然存活、不可回收。确定 live set 的标准做法是从 GC Roots(栈帧中的局部变量、静态字段等)出发,沿引用链遍历所有可达对象。 问题在于:当堆被划分为多个区域(代、Region)并且只回收其中一部分时,如何高效地找到从"不回收区域"指向"回收区域"的引用? 以 Young GC 为例:只回收新生代,但老年代中可能持有指向新生代对象的引用。如果不处理这些跨代引用,就会错误地回收仍被老年代引用的新生代对象。最朴素的做法是扫描整个老年代来找出这些引用——但老年代通常远大于新生代,这样做的代价过高,违背了分代收集"只回收一部分堆"的初衷。 卡表(Card Table)和 RSet(Remembered Set)正是为解决这个问题而设计的辅助数据结构。二者的关系并非互相替代,而是层次不同、协作互补:卡表是底层的脏标记机制,RSet 是建立在卡表之上的更高层索引结构。 核心概念速览 在深入细节之前,...
2026-02-07
G1/ZGC/Shenandoah 垃圾收集器对比
垃圾收集的核心挑战 垃圾收集器的设计始终面临三个核心指标的权衡:吞吐量、延迟和内存占用。这三个指标构成了一个不可能三角,优化其中一个指标往往需要牺牲其他指标。 吞吐量指单位时间内完成的工作量,通常用应用程序运行时间占总时间的比例来衡量。对于批处理任务、科学计算等场景,高吞吐量是首要目标。 延迟指垃圾收集造成的应用停顿时间。对于交互式应用、金融交易系统等对响应时间敏感的场景,低延迟至关重要。延迟通常关注最大停顿时间和停顿时间分布。 内存占用指垃圾收集器为了完成收集工作所需的额外内存空间。内存受限的环境下,收集器自身的内存开销成为关键约束。 传统垃圾收集器在三者之间做出明确取舍:Serial 和 Parallel GC 追求高吞吐量,但停顿时间较长;CMS GC 降低停顿时间,但牺牲吞吐量并占用更多内存。现代收集器试图在三者之间找到更优的平衡点。 G1(Garbage First)收集器 G1 收集器在 JDK 7u4 版本正式推出,是 JDK 9 之后的默认垃圾收集器。G1 的核心思想是打破传统分代收集的物理隔离,将堆内存划分为多个大小相等的 Region。 Region 化堆内存...
