- 浏览: 469249 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
mrshen:
很棒,在其他大神的博客上理清了思路看懂之后,来lz这里用例子学 ...
RED-BLACK(红黑)树的实现TreeMap源码阅读 -
a939639017:
yanf4j check不下来 ?
Java nio 2.0 AIO -
hellostory:
又是抄来的 - -
mysql分表方案 -
davidluoye:
为什么不说下支持的数据库呢?
模糊查询的优化 -
oliveevilo:
表示没看懂
Synchronized和java.util.concurrent.locks.Lock的区别
可能许多人都读到过资料,听说过在Sun的HotSpot VM里,client VM与server VM是共用一套解释器的。那么“照理说”无论是在client还是server模式,纯解释执行的性能应该是一样的。
引用
(图片来源:The Java HotSpot Performance Engine Architecture)
是这样的么?解释器虽然是同一个,但它却可以根据启动参数的不同而变得不同。
而且有很多因素会影响测试时间的小程序(microbenchmark)。解释器自身的性能是一点,VM里其它部分的情况又是一点,例如说GC。
昨天有朋友提到这样的问题:
引用
你好,前几天看了你的JVM分享的ppt,感觉收获颇多。看完后自己写了些代码测试,其中关于JVM启动参数对性能测试的影响方面,有个问题搞不懂,就是下面两种启动参数的设置,有什么不同:
引用
Command prompt代码
1.java -client -Xint
2.
3.java -server -Xint
我预想是没有差别的,因为都是解释执行,但测试时,发现第二种比第一种要快,难道client和server两种模式下,解释器的实现不一样?望赐教。我的测试代码如下:
Java代码
1.import java.util.Calendar;
2.
3.public class Main {
4. public static String getLastDayOfMonth(String yyyyMM, boolean addZero) {
5. Calendar calendar = Calendar.getInstance();
6. calendar.set(Integer.parseInt(yyyyMM.substring(0, 4)),
7. Integer.parseInt(yyyyMM.substring(4, 6)) - 1, 1);
8. calendar.add(Calendar.MONTH, 1);
9. calendar.add(Calendar.DAY_OF_MONTH, -1);
10. String day = "" + calendar.get(Calendar.DAY_OF_MONTH);
11. if (addZero && day.length() == 1) {
12. day = "0" + day;
13. }
14.
15. return day;
16. }
17.
18. public static void main(String[] args) {
19. for(int i = 0; i < 100000; i++) {
20. Main.getLastDayOfMonth("198503", true);
21. }
22.
23. long t1 = System.currentTimeMillis();
24. for(int i = 0; i < 100000; i++) {
25. Main.getLastDayOfMonth("198503", true);
26. }
27. long t2 = System.currentTimeMillis();
28. System.out.println(t2 - t1);
29. }
30.}
在我的机器上,client模式下执行是15.5秒左右,server模式是13秒左右,试了很多次,都是这样。
java -client -Xint与java -server -Xint,事实上这两种条件下由HotSpot VM最终生成出来的解释器代码确实不是完全一样的。
先前发过的JVM分享的PPT里也有提到,HotSpot VM的解释器是在启动的时候才动态生成的,其中好处之一就是它会根据启动参数来生成最小量必要的代码(理论上…)。这样生成出来的解释器就可以在当时的环境中最合适。
在client模式中,VM参数ProfileInterpreter默认是false,而在server模式中这个参数默认为true。
生成的解释器代码中,ProfileInterpreter对应一段额外的逻辑去收集profile数据,为了给JIT编译器提供更准确的信息做更高效的优化。例如说,开启了ProfileInterpreter之后,解释器的条件跳转字节码的处理逻辑里就会多了一段,记录到底有多少次是走了then分支,而多少走了else分支(准确来说是记录条件跳转的taken与not-taken)。可以参考一下TemplateTable::branch(bool is_jsr, bool is_wide)看看这是如何实现的。
所以server模式下的解释器应该比client模式下慢。
朋友继续问:
引用
RednaxelaFX 写道
为了给JIT编译器提供更准确的信息做更高效的优化,所以server模式下的解释器应该比client模式下慢
启动参数中已经设置了-Xint,是不是说程序会一直按解释执行,如果是的话,貌似就没有必要为JIT进行信息收集了。
还有,你说的ProfileInterpreter这个参数要如何设置,是使用-D吗?
嗯,虽说设定了纯解释模式之后HotSpot VM是没必要为JIT编译器收集profile数据,但现实是HotSpot的VM参数所控制到的点并不总是那么全面,而且参数众多,有些看起来相关的参数实际上影响了不同部分的代码。
前面提到的ProfileInterpreter的默认值就只受client/server VM的区别所影响,在client VM中它默认为false,在server VM中它默认为true。
-Xint等同于几个VM参数的组合;它只是确保了UseInterpreter参数为true,却并不关心ProfileInterpreter的值如何。
可以参考Arguments::set_mode_flags(Mode mode)的逻辑,看看-Xint、-Xmixed与-Xcomp到底设定了一些什么参数。
像这样的VM参数,在HotSpot中是通过启动时在命令行传入-XX:前缀加上参数名以及参数值来设定的。布尔类型的参数是在参数名之前写+或-来表示true或false。
例如说,要强制将ProfileInterpreter参数设置为true,可以在启动Java的命令行参数上加上-XX:+ProfileInterpreter。
HotSpot的VM参数也可以通过写一个.hotspotrc配置文件来指定。它就是个普通文本文件,每行写一个参数,参数不需要-XX:前缀。如果要指定ProfileInterpreter为true并且UseCompiler为true,则文件内容为:
.hotspotrc代码
1.+ProfileInterpreter
2.+UseCompiler
该配置文件放在启动Java进程的工作目录(working directory)中。
-D是用来传递一些值给Java进程设定它的系统属性(system properties)的。多数系统属性都可以在Java程序中通过System.getProperties()获取。这跟VM参数是两个概念。
=================================================================
下面就开头的测试代码具体分析一下。环境是JDK 6 update 24 x86。
用-XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter参数可以看到实际生成出来的解释器代码(需要hsdis插件):
java -client -Xint https://gist.github.com/924905
java -server -Xint https://gist.github.com/924901
可以留意比较一下两个版本里的解释器的代码差异,例如说ifeq,client版里的就明显比server版里的短。
两者的参数差异可以在这里看:https://gist.github.com/924906
可以留意几个,
VM参数
client
server
UseInterpreter
true
true
UseCompiler
false
false
ProfileInterpreter
false
true
UseOnStackReplacement
false
false
UseLoopCounter
false
false
BackgroundCompilation
true
true
实际运行一下那段测试代码的话,可以看到:
Command prompt代码
1.[sajia@sajia ~]$ java -client -Xint Main
2.9825
3.[sajia@sajia ~]$ java -client -Xint Main
4.9820
5.[sajia@sajia ~]$ java -client -Xint Main
6.9816
7.[sajia@sajia ~]$ java -server -Xint Main
8.9519
9.[sajia@sajia ~]$ java -server -Xint Main
10.9439
11.[sajia@sajia ~]$ java -server -Xint Main
12.9446
确实在我的测试机器上跑也是server模式的更快一些。但这个测试确实只反映了解释器自身的性能么?让我们再多看些数据。
实际上问题是出在GC算法上。client模式默认是用UseSerialGC,是单线程串行执行的;而server模式默认是用UseParallelGC,是多线程并行执行的,所以server模式的会快一些(按单位回收的空间大小来算,不要按单次停机时间来算因为堆大小可能不同)。
另外堆大小的默认选择也不同,server模式默认会用更大的GC堆,所以GC次数会比较少。
看下面的日志:
Command prompt代码
1.[sajia@sajia ~]$ java -client -Xint -XX:+PrintGCDetails Main
2.[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]
3.[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]
4.[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]
5.[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]
6.[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]
7.[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]
8.[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]
9.[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]
10.[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]
11.[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]
12.[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]
13.[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]
14.[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]
15.[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]
16.[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]
17.[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]
18.[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]
19.[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]
20.[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]
21.[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]
22.[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]
23.[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]
24.[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]
25.[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]
26.[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]
27.9841
28.Heap
29. def new generation total 4992K, used 1974K [0xbf710000, 0xbfc70000, 0xc4c60000)
30. eden space 4480K, 44% used [0xbf710000, 0xbf8fd8c0, 0xbfb70000)
31. from space 512K, 0% used [0xbfbf0000, 0xbfbf0000, 0xbfc70000)
32. to space 512K, 0% used [0xbfb70000, 0xbfb70000, 0xbfbf0000)
33. tenured generation total 10944K, used 160K [0xc4c60000, 0xc5710000, 0xcf710000)
34. the space 10944K, 1% used [0xc4c60000, 0xc4c881c8, 0xc4c88200, 0xc5710000)
35. compacting perm gen total 12288K, used 34K [0xcf710000, 0xd0310000, 0xd3710000)
36. the space 12288K, 0% used [0xcf710000, 0xcf718948, 0xcf718a00, 0xd0310000)
37. ro space 10240K, 61% used [0xd3710000, 0xd3d38a38, 0xd3d38c00, 0xd4110000)
38. rw space 12288K, 60% used [0xd4110000, 0xd4848ec0, 0xd4849000, 0xd4d10000)
39.
40.[sajia@sajia ~]$ java -server -Xint -XX:+PrintGCDetails Main
41.[GC [PSYoungGen: 14016K->198K(16320K)] 14016K->198K(53696K), 0.0024550 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
42.[GC [PSYoungGen: 14214K->174K(16320K)] 14214K->174K(53696K), 0.0016880 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
43.[GC [PSYoungGen: 14190K->174K(16320K)] 14190K->174K(53696K), 0.0013630 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
44.[GC [PSYoungGen: 14190K->174K(16320K)] 14190K->174K(53696K), 0.0017030 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
45.[GC [PSYoungGen: 14190K->174K(13888K)] 14190K->174K(51264K), 0.0014890 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
46.[GC [PSYoungGen: 13870K->174K(13568K)] 13870K->174K(50944K), 0.0017340 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
47.[GC [PSYoungGen: 13550K->16K(13120K)] 13550K->178K(50496K), 0.0018910 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
48.[GC [PSYoungGen: 13072K->0K(12864K)] 13234K->162K(50240K), 0.0007120 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
49.9482
50.Heap
51. PSYoungGen total 12864K, used 3073K [0xe1e30000, 0xe2dd0000, 0xf4230000)
52. eden space 12800K, 24% used [0xe1e30000,0xe21306d8,0xe2ab0000)
53. from space 64K, 0% used [0xe2dc0000,0xe2dc0000,0xe2dd0000)
54. to space 256K, 0% used [0xe2d50000,0xe2d50000,0xe2d90000)
55. PSOldGen total 37376K, used 162K [0xbd630000, 0xbfab0000, 0xe1e30000)
56. object space 37376K, 0% used [0xbd630000,0xbd6588c8,0xbfab0000)
57. PSPermGen total 16384K, used 1937K [0xb9630000, 0xba630000, 0xbd630000)
58. object space 16384K, 11% used [0xb9630000,0xb98146f8,0xba630000)
能看出区别来了么?
然后朋友回复:
引用
刚才我又试了一下,设置相同的堆大小,都用并行垃圾收集后,两者的运行时间基本一致(但貌似你机器的配置要比我好很多 ),如下:
Command prompt代码
1.C:\eclipse\workspace\JITTest\bin>java -client -Xint -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseParallelGC -XX:+PrintGCDetails Main
2.[GC [PSYoungGen: 15168K->240K(17664K)] 15168K->240K(259648K), 0.0017866 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
3.[GC [PSYoungGen: 15408K->208K(17664K)] 15408K->208K(259648K), 0.0011884 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
4.[GC [PSYoungGen: 15376K->224K(17664K)] 15376K->224K(259648K), 0.0009685 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
5.[GC [PSYoungGen: 15392K->224K(17664K)] 15392K->224K(259648K), 0.0009029 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
6.[GC [PSYoungGen: 15392K->224K(17664K)] 15392K->224K(259648K), 0.0009185 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
7.[GC [PSYoungGen: 15392K->208K(19904K)] 15392K->208K(261888K), 0.0010813 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
8.[GC [PSYoungGen: 19856K->16K(19712K)] 19856K->220K(261696K), 0.0011097 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
9.12782
10.Heap
11.PSYoungGen total 19712K, used 3160K [0x28280000, 0x29630000, 0x2a9e0000)
12. eden space 19648K, 16% used [0x28280000,0x285921b0,0x295b0000)
13. from space 64K, 25% used [0x295b0000,0x295b4000,0x295c0000)
14. to space 320K, 0% used [0x295e0000,0x295e0000,0x29630000)
15.PSOldGen total 241984K, used 204K [0x0a9e0000, 0x19630000, 0x28280000)
16. object space 241984K, 0% used [0x0a9e0000,0x0aa13060,0x19630000)
17.PSPermGen total 65536K, used 2470K [0x029e0000, 0x069e0000, 0x0a9e0000)
18. object space 65536K, 3% used [0x029e0000,0x02c49828,0x069e0000)
19.
20.C:\eclipse\workspace\JITTest\bin>java -server -Xint -Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m -XX:+UseParallelGC -XX:+PrintGCDetails Main
21.[GC [PSYoungGen: 21952K->240K(25536K)] 21952K->240K(258560K), 0.0016271 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
22.[GC [PSYoungGen: 22192K->208K(25536K)] 22192K->208K(258560K), 0.0011813 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
23.[GC [PSYoungGen: 22160K->224K(25536K)] 22160K->224K(258560K), 0.0009733 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]
24.[GC [PSYoungGen: 22176K->224K(25536K)] 22176K->224K(258560K), 0.0009282 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
25.[GC [PSYoungGen: 22176K->224K(25536K)] 22176K->224K(258560K), 0.0009107 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
26.12798
27.Heap
28.PSYoungGen total 25536K, used 4176K [0x28140000, 0x29db0000, 0x2ba20000)
29. eden space 21952K, 18% used [0x28140000,0x2851c170,0x296b0000)
30. from space 3584K, 6% used [0x296b0000,0x296e8040,0x29a30000)
31. to space 256K, 0% used [0x29d70000,0x29d70000,0x29db0000)
32.PSOldGen total 233024K, used 0K [0x0ba20000, 0x19db0000, 0x28140000)
33. object space 233024K, 0% used [0x0ba20000,0x0ba20000,0x19db0000)
34.PSPermGen total 65536K, used 2470K [0x03a20000, 0x07a20000, 0x0ba20000)
35. object space 65536K, 3% used [0x03a20000,0x03c89828,0x07a20000)
呵呵,确实如此。
因为解释器本来就比较慢,所以增加ProfileInterpreter并不会显著的增加开销,所以这部分开销才可以接受。但非要追究谁快谁慢的话,那还是client模式下默认生成的解释器会比server模式的快一些的。
发表评论
-
JDK内置工具使用(转)
2012-08-09 10:56 1222JDK内置工具使用 一、javah命令(C Header a ... -
jstack使用
2012-08-09 10:37 1573Java综合 我们使用jdk自带的jstack来分析。当lin ... -
jstat使用
2012-08-09 09:51 1180如何判断JVM是否存在内 ... -
java应用crash案例
2012-08-08 22:05 1232最近,应用总会时不时c ... -
一个java crash的故障分析过程
2012-08-08 22:01 2282一个应用在周五 ... -
Java进程Crash的故障分析方法(转)
2012-08-08 21:54 4957I、Java进程无故退出的 ... -
使用CORE DUMP
2012-08-08 20:59 1708程序出现SIGSEGV ,Segmenta ... -
( 转)JVM执行篇:使用HSDIS插件分析JVM代码执行细节
2012-08-08 20:10 967在《Java虚拟机规范》之 ... -
Java Crash问题分析
2012-08-05 18:36 1960如果是Java进程不知道 ... -
JVM性能优化
2012-04-26 10:30 1159本文主要根据这篇PDF(G ... -
Java编译器、JVM、解释器
2012-04-25 16:43 3032Java 虚拟机(JVM)是可运行 ... -
JVM执行篇:使用HSDIS插件分析JVM代码执行细节
2012-04-10 13:27 1347在《Java虚拟机规范》之 ... -
IcedTea在开源与OpenJDK的鸿沟上架起了桥梁
2011-11-22 23:54 17172008-06-12 18:06 作者: 来源:来自论坛 [ ... -
Sun的JDK7、OpenJDK及IcedTea释疑
2011-11-22 23:44 1282http://www.infoq.com/cn/news/20 ... -
在XUbuntu 10.10上以JRL源码构建Oracle JDK 6 update 23
2011-11-22 23:00 1967http://rednaxelafx.iteye.com/bl ... -
n JDK 和 OpenJDK 的区别
2011-11-22 13:34 2263http://hi.baidu.com/openware/bl ... -
线程局部存储Thread Local Storage-TLS(总结整理)
2011-10-27 18:18 1783在线程的学习中我们知道每个线程除了共享进程的资源外还拥有各 ... -
c++阿里笔试
2011-10-26 14:43 17211、有一个虚拟存储系统 ... -
GDB调试精粹及使用实例
2011-10-12 14:41 1074一:列文件清单 1. List (gdb) list li ... -
Mercurial学习笔记
2011-10-11 13:06 6712录 •1 Mercurial 一览: 基础 ◦1.1 ...
相关推荐
1. 解释器:Hotspot VM最初使用解释器来执行字节码,这是一种快速启动但执行速度相对较慢的方式。 2. 编译器:随着程序的运行,Hotspot VM会识别出执行频率高的“热点”代码,并使用Just-In-Time (JIT) 编译器将其...
HotSpot包括一个解释器和两个编译器(client 和 server,二选一的),解释与编译混合执行模式,默认启动解释执行。 编译器:java源代码被编译器编译成class文件(字节码),java字节码在运行时可以被动态编译(JIT)...
Hotspot JVM支持两种编译模式:client模式和server模式。client模式注重快速启动和较小的内存占用,而server模式则专注于峰值代码生成性能。在Java堆管理方面,Hotspot提供了三种垃圾回收器:Serial(客户端)、...
在JDK6及以后的版本中,HotSpot引入了多层编译的概念,解释器与C1、C2协同工作。多层编译提供了不同的编译级别,每个级别对应不同的优化策略: 1. 第0级(CompLevel_none):使用解释器执行,不收集性能数据,可...
下次调用该方法时,VM会跳过解释器,直接通过nmethod的入口点执行本地代码。 - 在`call_stub`中,`StubRoutines::call_stub()`是一个平台相关的调用约定,用于调用生成的本地代码。 在描述中提到的`compile_method...
- **混合执行模式**:结合了解释器和即时编译器(Just-In-Time Compiler, JIT),可以根据代码的执行频率动态选择编译或解释执行。 - **动态编译**:对于执行频率高的“热点”代码进行动态编译,以提高性能。 ###...
理解HotSpot VM中的Client Compiler和Server Compiler的区别有助于理解JVM的运行模式。 10. **异常处理与类加载器自定义**:理解和熟悉Java异常处理机制,以及如何自定义类加载器以实现特定的功能,如加载动态生成...
10. **性能优化**: 对JVM进行了多方面的优化,包括更快的类加载、更快的字节码解释和更高效的编译器(如Client和Server模式的HotSpot VM)。 虽然JDK 1.6已经是个较旧的版本,但它仍然是许多遗留系统的基础。如果你...
Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing) ``` ##### 4.2 服务器端JVM示例 如果想要查看服务器端JVM的信息,则需要显式指定使用`-server`选项。例如,在设置了`PATH`变量包含`jdk\...
7. **编译优化**:JVM可以进行即时编译(JIT),将热点代码编译为机器码以提高性能,比如HotSpot JVM的Client Compiler和Server Compiler。 8. **线程模型**:JVM如何处理并发,包括线程创建、同步、死锁等问题。 ...
早期的JVM使用解释器逐条解释执行字节码,现代的HotSpot JVM则采用了即时编译(JIT,Just-In-Time)技术,将热点代码编译成本地机器码以提高执行效率。 4. **Native Interface**:本地接口允许Java代码调用C/C++等...
Java HotSpot(TM) Client VM (build 1.6.0_02-n06, mixed mode, sharing) ``` 这表明系统已经正确识别并配置了JDK版本。 ### 数据库连接配置 对于涉及数据库操作的Java应用,还需配置数据库连接。如示例中提到的...
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) C:\Documents and Settings\Administrator>catalina -version Using CATALINA_BASE: D:\jakarta-tomcat-5.0.30 Using CATALINA_HOME: D:\...
- **Step 2:初始配置**:根据系统的具体需求选择-server或-client模式;调整-Xmx和-Xms的值;设置年轻代和年老代的比例等。 - **Step 3:持续监控**:在调优过程中持续监控JVM的状态,通过日志分析工具观察性能指标...
- **Java HotSpot Client VM**:适用于客户端应用,具有较小的内存占用和较快的启动速度。 - **Java HotSpot Server VM**:针对服务器端应用进行了优化,能够处理高负载的应用场景。 ### 支持的操作系统平台 - **...