HotSpot VM里的解释器在client与server模式上的一点区别

最新推荐文章于 2021-02-21 10:47:55 发布
最新推荐文章于 2021-02-21 10:47:55 发布
阅读量131 收藏
点赞数
分类专栏： Virtual Machine 文章标签： ITeye Eclipse JVM Oracle .net
可能许多人都读到过资料，听说过在Sun的HotSpot VM里，client VM与server VM是共用一套解释器的。那么[i]“照理说”[/i]无论是在client还是server模式，纯解释执行的性能应该是一样的。
[quote][img]http://dl.iteye.com/upload/attachment/466044/d3539ed1-fdfe-3a1a-a070-f763d23142dc.gif[/img][/quote]
（图片来源：[url=http://www.oracle.com/technetwork/java/whitepaper-135217.html]The Java HotSpot Performance Engine Architecture[/url]）

是这样的么？解释器虽然是同一个，但它却可以根据启动参数的不同而变得不同。
而且有很多因素会影响测试时间的小程序（microbenchmark）。解释器自身的性能是一点，VM里其它部分的情况又是一点，例如说GC。

昨天有朋友提到这样的问题：
[quote]你好，前几天看了你的JVM分享的ppt，感觉收获颇多。看完后自己写了些代码测试，其中关于JVM启动参数对性能测试的影响方面，有个问题搞不懂，就是下面两种启动参数的设置，有什么不同：
[quote] 
java -client -Xint

java -server -Xint
[/quote]
我预想是没有差别的，因为都是解释执行，但测试时，发现第二种比第一种要快，难道client和server两种模式下，解释器的实现不一样？望赐教。我的测试代码如下： 
import java.util.Calendar;

public class Main {
    public static String getLastDayOfMonth(String yyyyMM, boolean addZero) {
        Calendar calendar = Calendar.getInstance();
        calendar.set(Integer.parseInt(yyyyMM.substring(0, 4)), 
                Integer.parseInt(yyyyMM.substring(4, 6)) - 1, 1);
        calendar.add(Calendar.MONTH, 1);
        calendar.add(Calendar.DAY_OF_MONTH, -1);
        String day = "" + calendar.get(Calendar.DAY_OF_MONTH);
        if (addZero && day.length() == 1) {
            day = "0" + day;
        }

        return day;
    }

    public static void main(String[] args) {
        for(int i = 0; i < 100000; i++) {
            Main.getLastDayOfMonth("198503", true);
        }

        long t1 = System.currentTimeMillis();
        for(int i = 0; i < 100000; i++) {
            Main.getLastDayOfMonth("198503", true);
        }
        long t2 = System.currentTimeMillis();
        System.out.println(t2 - t1);
    }
}

在我的机器上，client模式下执行是15.5秒左右，server模式是13秒左右，试了很多次，都是这样。[/quote]

java -client -Xint与java -server -Xint，事实上这两种条件下[b]由HotSpot VM最终生成出来的解释器代码[/b]确实不是完全一样的。

[url=http://rednaxelafx.iteye.com/blog/858009]先前发过的JVM分享的PPT[/url]里也有提到，HotSpot VM的解释器是在启动的时候才动态生成的，其中好处之一就是它会根据启动参数来生成最小量必要的代码（理论上…）。这样生成出来的解释器就可以在当时的环境中最合适。

在client模式中，VM参数[b]ProfileInterpreter[/b]默认是false，而在server模式中这个参数默认为true。
生成的解释器代码中，ProfileInterpreter对应一段额外的逻辑去收集profile数据，为了给JIT编译器提供更准确的信息做更高效的优化。例如说，开启了ProfileInterpreter之后，解释器的条件跳转字节码的处理逻辑里就会多了一段，记录到底有多少次是走了then分支，而多少走了else分支（准确来说是记录条件跳转的taken与not-taken）。可以参考一下[url=http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/tip/src/cpu/x86/vm/templateTable_x86_32.cpp]TemplateTable::branch(bool is_jsr, bool is_wide)[/url]看看这是如何实现的。

所以server模式下的解释器应该比client模式下[b]慢[/b]。

朋友继续问：
[quote][quote="RednaxelaFX"]为了给JIT编译器提供更准确的信息做更高效的优化，所以server模式下的解释器应该比client模式下[b]慢[/b][/quote]
启动参数中已经设置了-Xint，是不是说程序会一直按解释执行，如果是的话，貌似就没有必要为JIT进行信息收集了。

还有，你说的ProfileInterpreter这个参数要如何设置，是使用-D吗？[/quote]

嗯，虽说设定了纯解释模式之后HotSpot VM是没必要为JIT编译器收集profile数据，但现实是HotSpot的VM参数所控制到的点并不总是那么全面，而且参数众多，有些看起来相关的参数实际上影响了不同部分的代码。

前面提到的ProfileInterpreter的默认值就只受client/server VM的区别所影响，在[url=http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/tip/src/cpu/x86/vm/c1_globals_x86.hpp]client VM中它默认为false[/url]，在[url=http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/tip/src/cpu/x86/vm/c2_globals_x86.hpp]server VM中它默认为true[/url]。

[b]-Xint[/b]等同于几个VM参数的组合；它只是确保了[b]UseInterpreter[/b]参数为true，却并不关心ProfileInterpreter的值如何。
可以参考[url=http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/tip/src/share/vm/runtime/arguments.cpp]Arguments::set_mode_flags(Mode mode)[/url]的逻辑，看看-Xint、-Xmixed与-Xcomp到底设定了一些什么参数。

像这样的[b]VM参数[/b]，在HotSpot中是通过启动时在命令行传入-XX:前缀加上参数名以及参数值来设定的。布尔类型的参数是在参数名之前写+或-来表示true或false。
例如说，要强制将ProfileInterpreter参数设置为true，可以在启动Java的命令行参数上加上[b]-XX:+ProfileInterpreter[/b]。

HotSpot的VM参数也可以通过写一个.hotspotrc配置文件来指定。它就是个普通文本文件，每行写一个参数，参数不需要-XX:前缀。如果要指定ProfileInterpreter为true并且UseCompiler为true，则文件内容为： 
+ProfileInterpreter
+UseCompiler

该配置文件放在启动Java进程的工作目录（working directory）中。

[b]-D[/b]是用来传递一些值给Java进程设定它的系统属性（system properties）的。多数系统属性都可以在Java程序中通过System.getProperties()获取。这跟VM参数是两个概念。

=================================================================

下面就开头的测试代码具体分析一下。环境是JDK 6 update 24 x86。

用-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter参数可以看到实际生成出来的解释器代码（需要[url=http://hllvm.group.iteye.com/group/topic/21769]hsdis插件[/url]）：
java -client -Xint [url]https://gist.github.com/924905[/url]
java -server -Xint [url]https://gist.github.com/924901[/url]
可以留意比较一下两个版本里的解释器的代码差异，例如说ifeq，client版里的就明显比server版里的短。

两者的参数差异可以在这里看：[url]https://gist.github.com/924906[/url]
可以留意几个，
[table]| VM参数 | client | server |
| UseInterpreter | true | true |
| UseCompiler | false | false |
| ProfileInterpreter | [color=red]false[/color] | [color=red]true[/color] |
| UseOnStackReplacement | false | false |
| UseLoopCounter | false | false |
| BackgroundCompilation | true | true |
[/table]

实际运行一下那段测试代码的话，可以看到： 
[sajia@sajia ~]$ java -client -Xint Main
9825
[sajia@sajia ~]$ java -client -Xint Main
9820
[sajia@sajia ~]$ java -client -Xint Main
9816
[sajia@sajia ~]$ java -server -Xint Main
9519
[sajia@sajia ~]$ java -server -Xint Main
9439
[sajia@sajia ~]$ java -server -Xint Main
9446

确实在我的测试机器上跑也是server模式的更快一些。但这个测试确实只反映了解释器自身的性能么？让我们再多看些数据。

实际上问题是出在GC算法上。client模式默认是用UseSerialGC，是单线程串行执行的；而server模式默认是用UseParallelGC，是多线程并行执行的，所以server模式的会快一些（按单位回收的空间大小来算，不要按单次停机时间来算因为堆大小可能不同）。
另外堆大小的默认选择也不同，server模式默认会用更大的GC堆，所以GC次数会比较少。
看下面的日志： 
[sajia@sajia ~]$ java -client -Xint -XX:+PrintGCDetails Main
[GC [DefNew: 4416K->161K(4928K), 0.0020070 secs] 4416K->161K(15872K), 0.0020790 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4577K->160K(4928K), 0.0011860 secs] 4577K->160K(15872K), 0.0012290 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0009230 secs] 4576K->160K(15872K), 0.0009630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0008960 secs] 4576K->160K(15872K), 0.0009350 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0010020 secs] 4576K->160K(15872K), 0.0010450 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0009180 secs] 4576K->160K(15872K), 0.0009610 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007820 secs] 4576K->160K(15872K), 0.0008220 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007600 secs] 4576K->160K(15872K), 0.0007970 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0009750 secs] 4576K->160K(15872K), 0.0010160 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007790 secs] 4576K->160K(15872K), 0.0008170 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007540 secs] 4576K->160K(15872K), 0.0007900 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0009090 secs] 4576K->160K(15872K), 0.0009490 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007940 secs] 4576K->160K(15872K), 0.0008310 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007470 secs] 4576K->160K(15872K), 0.0007840 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->160K(4928K), 0.0007630 secs] 4576K->160K(15872K), 0.0008010 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4576K->0K(4928K), 0.0010530 secs] 4576K->160K(15872K), 0.0011120 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0003780 secs] 4640K->160K(15936K), 0.0004160 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001560 secs] 4640K->160K(15936K), 0.0001920 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001450 secs] 4640K->160K(15936K), 0.0001800 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001430 secs] 4640K->160K(15936K), 0.0001790 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001420 secs] 4640K->160K(15936K), 0.0001780 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001480 secs] 4640K->160K(15936K), 0.0001840 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001680 secs] 4640K->160K(15936K), 0.0002080 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001700 secs] 4640K->160K(15936K), 0.0002070 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [DefNew: 4480K->0K(4992K), 0.0001540 secs] 4640K->160K(15936K), 0.0001890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
9841
Heap
 def new generation   total 4992K, used 1974K [0xbf710000, 0xbfc70000, 0xc4c60000)
  eden space 4480K,  44% used [0xbf710000, 0xbf8fd8c0, 0xbfb70000)
  from space 512K,   0% used [0xbfbf0000, 0xbfbf0000, 0xbfc70000)
  to   space 512K,   0% used [0xbfb70000, 0xbfb70000, 0xbfbf0000)
 tenured generation   total 10944K, used 160K [0xc4c60000, 0xc5710000, 0xcf710000)
   the space 10944K,   1% used [0xc4c60000, 0xc4c881c8, 0xc4c88200, 0xc5710000)
 compacting perm gen  total 12288K, used 34K [0xcf710000, 0xd0310000, 0xd3710000)
   the space 12288K,   0% used [0xcf710000, 0xcf718948, 0xcf718a00, 0xd0310000)
    ro space 10240K,  61% used [0xd3710000, 0xd3d38a38, 0xd3d38c00, 0xd4110000)
    rw space 12288K,  60% used [0xd4110000, 0xd4848ec0, 0xd4849000, 0xd4d10000)

[sajia@sajia ~]$ java -server -Xint -XX:+PrintGCDetails Main
[GC [PSYoungGen: 14016K->198K(16320K)] 14016K->198K(53696K), 0.0024550 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
[GC [PSYoungGen: 14214K->174K(16320K)] 14214K->174K(53696K), 0.0016880 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 14190K->174K(16320K)] 14190K->174K(53696K), 0.0013630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 14190K->174K(16320K)] 14190K->174K(53696K), 0.0017030 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 14190K->174K(13888K)] 14190K->174K(51264K), 0.0014890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 13870K->174K(13568K)] 13870K->174K(50944K), 0.0017340 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 13550K->16K(13120K)] 13550K->178K(50496K), 0.0018910 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 13072K->0K(12864K)] 13234K->162K(50240K), 0.0007120 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
9482
Heap
 PSYoungGen      total 12864K, used 3073K [0xe1e30000, 0xe2dd0000, 0xf4230000)
  eden space 12800K, 24% used [0xe1e30000,0xe21306d8,0xe2ab0000)
  from space 64K, 0% used [0xe2dc0000,0xe2dc0000,0xe2dd0000)
  to   space 256K, 0% used [0xe2d50000,0xe2d50000,0xe2d90000)
 PSOldGen        total 37376K, used 162K [0xbd630000, 0xbfab0000, 0xe1e30000)
  object space 37376K, 0% used [0xbd630000,0xbd6588c8,0xbfab0000)
 PSPermGen       total 16384K, used 1937K [0xb9630000, 0xba630000, 0xbd630000)
  object space 16384K, 11% used [0xb9630000,0xb98146f8,0xba630000)

能看出区别来了么？

然后朋友回复：
[quote]刚才我又试了一下，设置相同的堆大小，都用并行垃圾收集后，两者的运行时间基本一致（但貌似你机器的配置要比我好很多 :D ），如下： 
C:\eclipse\workspace\JITTest\bin>java -client -Xint -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseParallelGC  -XX:+PrintGCDetails Main 
[GC [PSYoungGen: 15168K->240K(17664K)] 15168K->240K(259648K), 0.0017866 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
[GC [PSYoungGen: 15408K->208K(17664K)] 15408K->208K(259648K), 0.0011884 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 15376K->224K(17664K)] 15376K->224K(259648K), 0.0009685 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 15392K->224K(17664K)] 15392K->224K(259648K), 0.0009029 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 15392K->224K(17664K)] 15392K->224K(259648K), 0.0009185 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 15392K->208K(19904K)] 15392K->208K(261888K), 0.0010813 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 19856K->16K(19712K)] 19856K->220K(261696K), 0.0011097 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
12782 
Heap 
PSYoungGen      total 19712K, used 3160K [0x28280000, 0x29630000, 0x2a9e0000) 
  eden space 19648K, 16% used [0x28280000,0x285921b0,0x295b0000) 
  from space 64K, 25% used [0x295b0000,0x295b4000,0x295c0000) 
  to   space 320K, 0% used [0x295e0000,0x295e0000,0x29630000) 
PSOldGen        total 241984K, used 204K [0x0a9e0000, 0x19630000, 0x28280000) 
  object space 241984K, 0% used [0x0a9e0000,0x0aa13060,0x19630000) 
PSPermGen       total 65536K, used 2470K [0x029e0000, 0x069e0000, 0x0a9e0000) 
  object space 65536K, 3% used [0x029e0000,0x02c49828,0x069e0000) 

C:\eclipse\workspace\JITTest\bin>java -server -Xint -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseParallelGC  -XX:+PrintGCDetails Main 
[GC [PSYoungGen: 21952K->240K(25536K)] 21952K->240K(258560K), 0.0016271 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 22192K->208K(25536K)] 22192K->208K(258560K), 0.0011813 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 22160K->224K(25536K)] 22160K->224K(258560K), 0.0009733 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
[GC [PSYoungGen: 22176K->224K(25536K)] 22176K->224K(258560K), 0.0009282 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC [PSYoungGen: 22176K->224K(25536K)] 22176K->224K(258560K), 0.0009107 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
12798 
Heap 
PSYoungGen      total 25536K, used 4176K [0x28140000, 0x29db0000, 0x2ba20000) 
  eden space 21952K, 18% used [0x28140000,0x2851c170,0x296b0000) 
  from space 3584K, 6% used [0x296b0000,0x296e8040,0x29a30000) 
  to   space 256K, 0% used [0x29d70000,0x29d70000,0x29db0000) 
PSOldGen        total 233024K, used 0K [0x0ba20000, 0x19db0000, 0x28140000) 
  object space 233024K, 0% used [0x0ba20000,0x0ba20000,0x19db0000) 
PSPermGen       total 65536K, used 2470K [0x03a20000, 0x07a20000, 0x0ba20000) 
  object space 65536K, 3% used [0x03a20000,0x03c89828,0x07a20000)
[/quote]
呵呵，确实如此。

因为解释器本来就比较慢，所以增加ProfileInterpreter并不会显著的增加开销，所以这部分开销才可以接受。但非要追究谁快谁慢的话，那还是client模式下默认生成的解释器会比server模式的快一些的。
rednaxelafx
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
hotspot.tar.gz
12-07
1. 解释器：Hotspot VM最初使用解释器来执行字节码，这是一种快速启动但执行速度相对较慢的方式。 2. 编译器：随着程序的运行，Hotspot VM会识别出执行频率高的“热点”代码，并使用Just-In-Time (JIT) 编译器将其...
JVM is using the client VM [Java HotSpot Client VM] but should be using a server VM for the best pe
hnhroot的博客
11-23 404
意思是当前jvm是Java HotSpot Client VM(-client)，而应该使用的是Java HotSpot Server VM(-server)，前者如其名称，应该适合在客户端使用，后者则适合在服务器环境中使用。 所以只需要从Java HotSpot Client VM(-client)切换到Java HotSpot Server VM(-server)就行。 找到jre目录，切换到该下 cd /usr/local/jdk/jdk1.8.0_05/jre 然后修改 ./lib/i386/jv
JVM的客户端与服务端，java HotSpot Client VM与java HotSpot Server VM
qq_26779961的博客
03-28 622
JVM的客户端与服务端，java HotSpot Client VM与java HotSpot Server VMJVM优化的点 JVM优化的点 JDK包括2个JVM的实现 1、java HotSpot Client VM 为在客户端环境中减少启动时间而优化 2、java HotSpot Server VM 为在 服务器环境中最大程序执行速度而设计。 两种方式各有优缺点， 比较：Server V...
[转]Java HotSpot Client VM 和 Java HotSpot Server VM的配置
雨笋情缘的专栏
07-08 151
原文摘自 JDK包括2个JVM的实现 JavaHotSpot Client VM(-client)，为在客户端环境中减少启动时间而优化； javaHotSpot Server VM(-server)，为在服务器环境中最大化程序执行速度而设计。 比较：Server VM启动比Client VM慢，运行比Client VM快...
java hotspot client_jvm HotSpot client VM 与 server VM
weixin_29204121的博客
02-21 177
Apusic 在启动的时候使用了 -server参数/usr/java/jdk1.6.0_14/bin/java -Dcom.apusic.domain.home=/app/apusic-5.1/domains/mydomain -server -Xms2048m -Xmx2048m -XX:MaxPermSize=512m -classpath .:/app/apusic-5.1/classes...
hotspot 虚拟机的server和client模式
蜗牛学习笔记
11-29 9003
hotspot包括server和client两种模式的实现： Java HotSpot Client VM(-client)，为在客户端环境中减少启动时间而优化； Java HotSpot Server VM(-server)，为在服务器环境中最大化程序执行速度而设计。 比较：Server VM启动比Client VM慢，运行比Client VM快。 server模式的运行中，垃圾回收处理做的比较好一些。
Hotspot 虚拟机源码 jdk8u
最新发布
07-02
HotSpot包括一个解释器和两个编译器（client 和 server，二选一的），解释与编译混合执行模式，默认启动解释执行。 编译器：java源代码被编译器编译成class文件（字节码），java字节码在运行时可以被动态编译（JIT）...
JVM优化与OOM分析PPT
10-10
- **Step 2：初始配置**：根据系统的具体需求选择-server或-client模式；调整-Xmx和-Xms的值；设置年轻代和年老代的比例等。 - **Step 3：持续监控**：在调优过程中持续监控JVM的状态，通过日志分析工具观察性能指标...
HotspotInAction.第250页 7.3 即时编译器 7.3.1 概述1
08-03
在JDK6及以后的版本中，HotSpot引入了多层编译的概念，解释器与C1、C2协同工作。多层编译提供了不同的编译级别，每个级别对应不同的优化策略： 1. 第0级（CompLevel_none）：使用解释器执行，不收集性能数据，可...
JVM的相关知识整理和学习
01-27
早期的JVM使用解释器逐条解释执行字节码，现代的HotSpot JVM则采用了即时编译（JIT，Just-In-Time）技术，将热点代码编译成本地机器码以提高执行效率。 4. **Native Interface**：本地接口允许Java代码调用C/C++等...
Java HotSpot Client VM 和 Java HotSpot Server VM的配置
清风小阁
01-05 1万+
JDK包括2个JVM的实现 Java HotSpot Client VM(-client)，为在客户端环境中减少启动时间而优化； Java HotSpot Server VM(-server)，为在服务器环境中最大化程序执行速度而设计。 比较：Server VM启动比Client VM慢，运行比Client VM快。 如何将VM设置成 Server VM： 找到 [jre安装目录]/
JDK8 Windows系统中Java HotSpot虚拟机配置参数
纸上得来终觉浅，绝知此事要躬行
04-02 4969
原文地址：http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html 目录 选项说明 标准选项 -agentlib:libname[=options] -agentpath:pathname[=options] -client -Dproperty=value -dsa -ea[:[packagen...
什么是HotSpot VM & 深入理解Java虚拟机 JVM
小诸葛的博客
06-21 1856
https://www.cnblogs.com/charlesblc/p/5993804.html
Java HotSpot(TM) Client VM 与 server VM 的配置
weixin_30687811的博客
04-26 2458
在Linux 6.5 下安装Elasticsearch 出现错误： JVM is using the client VM [Java HotSpot(TM) Client VM] but should be using a server VM for the best performance JVM正在使用客户机VM [Java HotSpot(TM)客户机VM]，但是为了获得最佳...
JVM is using the client VM [Java HotSpot(TM) Client VM] but should be using a server VM
yanghao201607030101的博客
07-11 1899
意思是当前jvm是Java HotSpot Client VM(-client)，而应该使用的是Java HotSpot Server VM(-server)，前者如其名称，应该适合在客户端使用，后者则适合在服务器环境中使用。 所以只需要从Java HotSpot Client VM(-client)切换到Java HotSpot Server VM(-server)就行。 找到jre目录，切换到该下 [root@aubin ~]# find / -name jre /usr/lib/jvm/java-1.
JAVA HOTSPOT VM参数大全
weixin_30892889的博客
10-13 164
（本文JDK版本6.0） SUN的JDK版本从1.3.1开始使用HotSpot虚拟机技术。 HotSpot是较新的Java虚拟机技术，用来代替JIT（Just in Time）技术，可以大大提高Java运行的性能。 Java原先是把源代码编译为字节码在虚拟机执行，这样执行速度较慢。而该技术将常用的部分代码编译为本地（原生，native）代码，这样 显著提高...
Java HotSpot Client VM 和 Java HotSpot Server VM的配置.
wanggangabc111的专栏
08-03 6004
JDK包括2个JVM的实现 Java HotSpot Client VM(-client)，为在客户端环境中减少启动时间而优化； java HotSpot Server VM(-server)，为在服务器环境中最大化程序执行速度而设计。 比较：Server VM启动比Client VM慢，运行比Client VM快。 如何将VM设置成 Server VM： 找到 [jdk安装目录]j
jdk运行模式client vm与server vm区别
热门推荐
【小石头的茅坑】
03-27 43万+
Client VM模式 输入java -version命令： java version "1.8.0_161" Java(TM) SE Runtime Environment (build 1.8.0_161-b12) Java HotSpot(TM) Client VM (build 25.161-b12, mixed mode) Server VM模式 输入java -versio...
Java性能优化宝典：G1垃圾收集器与HotSpot VM深度解析
该书在Java® Performance经典之作基础上，着重介绍了两个关键的Java平台创新：Garbage First (G1) 垃圾回收器和HotSpot VM Serviceability Agent。 首先，G1垃圾收集器是针对现代多核硬件和复杂操作系统环境中的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值