client 与 server
Created|Updated
|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

2019-09-02
《JVM 问题分析处理总结》笔记
知识体系图谱 紧急处理原则 出现问题应该第一时间恢复,恢复过程中如果有余地则要保留问题现场供后面排查定位问题,其基本步骤是: 打印堆栈信息 打印内存镜像 生成core文件 保留gc日志文件 保留业务日志文件 查看JAVA堆内存运行分配 如果有余地,可以做完以上的操作后再重启应用。 实例 实例一 1 查看 gc 日志,评估代际问题。 2 查看访问日志,看看应用吞吐量。 3 用 jstat 查看代际问题。 4 把内存 dump 出来,分析数量最多的对象。 5 分析代码。 6 改善代码。 实例二 1 统计线程总数:ps -eLf | grep java -c 2 看 ulimit -u 3 jstack、gcore 4 改善 jvm 参数

2026-01-18
无锁队列
Java 一读一写(SPSC):Memory Barrier + Volatile 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657/** * Single-Producer Single-Consumer (SPSC) 无锁环形队列。 * * <p>原理说明: * - 仅允许一个线程调用 {@code offer()},一个线程调用 {@code poll()}。 * - 由于没有写竞争,无需 CAS;只需保证写操作对消费者可见。 * - 使用两个 volatile 索引(head/tail)建立 happens-before 关系: * 生产者写入元素 → volatile 写 tail → 消费者 volatile 读 tail → 读取元素。 * - 这本质上利用了 Java 内存模型中的“volatile 写-读”内存屏障(StoreLoad), * ...

2019-09-05
重述双亲委派模型
何时加载类 根据 Java 语言规范(JLS §12.4),类或接口在首次主动使用时才会被初始化。主动使用包括以下情况: 遇到 new、getstatic、putstatic、invokestatic 等字节码指令时。这些指令分别对应创建对象实例、读取或设置静态字段、调用静态方法。 对类进行反射调用时,如 Class.forName() 或 Method.invoke()。 初始化某个类的子类时,父类会先被初始化(但父类接口不会)。 虚拟机启动时会先加载设置的主类,即包含 main() 方法的类。 使用 java.lang.invoke 包的动态语言支持特性时,如 MethodHandle 调用。 需要注意的是,被动引用(如通过数组引用、常量引用、访问子类的静态字段等)不会触发类初始化。 从 Java 到 cpp 源码分析 双亲委派模型的工作流程 双亲委派模型的核心逻辑在 java.lang.ClassLoader.loadClass(String name, boolean resolve) 方法中: 123456789101112131415161718192021222...

2018-10-22
JDWP 与远程调试
JDWP(Java Debug Wire Protocol),它提供了调试器和目标 JVM (target vm)之间的调试协议。 在 target vm 启动时,增加这个 JAVA_OPTS: 1JAVA_OPTS="-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=26310" 在服务器端,增加 remote debuging 的时候使用如下配置: 12345678# Java 9 以上-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000# Java 5-8-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000# Java 1.4.x -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,addre...

2020-09-27
现代垃圾收集器
所有的垃圾收集器,都基于弱分代假设。实际的垃圾回收效率取决于堆内对象的分布状况。垃圾回收并不能解决内存泄漏或者应用程序逻辑的不良分配习惯问题,要处理 JVM 内存回收问题的根本方法是对程序进行调优。 有几个常用原则: 减少临时对象,尽量复用内存。 使用对象池。 主动提前释放对象。 主动 gc。 好的代码比 tuning 更重要。 选 gc 算法比 tuning 参数重要,tuning 参数是最后一步。 其他情况,可以通过 tuning garbage collector 来解决。 操作系统的影响 SWAP 可能会显著增加 GC 时间,因为被换出的堆还要被换入。 美团的实践 参考: 《从实际案例聊聊Java应用的GC优化》 《Java中9种常见的CMS GC问题分析与解决》 Minor GC Major GC Full GC 垃圾收集器分类 可以看到一个现象:在大部分时候,g1 比 CMS 快,但极端的百分位里,CMS 比 g1 快。 出处见这里。 常用工具 命令行终端 标准终端类:jps、jinfo、jstat、jstack、jmap 功能整合类:jcm...

2017-10-23
昂贵的异常
抛出问题 Joshua Bloch 在《Effective Java》的 Item 57 里明确地提到过,不要试图用 Exception 的跳转来代替正常的程序控制流。他列举了很多原因,但特别提到了抛出异常会使得整个程序运行变慢。抛出异常远比普通的 return、break 等操作对控制流、数据流的性能影响要大,它就只适合拿来作异常分支的控制语句,而不能拿来编写正常的逻辑。 Throwing exception is expensive. 这句话在 Java 的程序员世界里面已经成为老生常谈,却很少有人谈及到底抛出异常比正常的程序跳转返回慢在哪里,有多慢。"不要滥用异常"好像一个猴子定律,人们知道不能这么做,却不明白为什么不能这么做。 此前读了一位同事写的好文《Java虚拟机是如何处理异常的》,深入地分析了 JVM 对异常跳转的处理过程:JVM 会通过异常表的机制,优化异常抛出和正常返回之间的性能差异。仅从程序计数器的移动上来讲,抛出一个异常对栈帧的弹栈并不比直接返回更昂贵。写在前头的结论是:"try-catch 语句块几乎不会影响程序运行性能!...