ArrayList 插入1000万条数据之后，我怀疑了jvm...

￡神魔★判官ぃ 2023-06-10 10:23 219阅读 0赞

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

扫描下方海报 **试读**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 1]

![640?wx\_fmt=png][640_wx_fmt_png]本文来源：占小狼的博客

"狼哥，我发现新大陆了，等会发你代码" "咋了，这么激动" "等会..."

List<Integer> list0 = new ArrayList<Integer>();	
    long start0 = System.currentTimeMillis();	
    for (int i = 0; i < 10000000; i++) {	
        list0.add(i);	
    }	
    System.out.println(System.currentTimeMillis() - start0);	
    long start1 = System.currentTimeMillis();	
    List<Integer> list1 = new ArrayList<Integer>();	
    for (int i = 10000000; i < 20000000; i++) {	
        list1.add(i);	
    }	
    System.out.println(System.currentTimeMillis() - start1);

"我在一个ArrayList中连续插入1千万条数据，结果耗时不一样，分别是 2346 797 没搞明白"

**我看了一眼，就知道这小伙底盘不稳。**

"你加个 -XX:+PrintGCDetails -XX:+PrintGCDateStamps，看下第一次是不是有Full GC"

"明白，我再试试看"

几分钟后...

2019-09-28T09:49:07.519-0800: [GC (Allocation Failure) [PSYoungGen: 54888K->10738K(76288K)] 54888K->36180K(251392K), 0.0520111 secs] [Times: user=0.24 sys=0.03, real=0.06 secs] 	
    2019-09-28T09:49:07.590-0800: [GC (Allocation Failure) [PSYoungGen: 74092K->10736K(141824K)] 99534K->80803K(316928K), 0.0693607 secs] [Times: user=0.39 sys=0.03, real=0.06 secs] 	
    2019-09-28T09:49:07.751-0800: [GC (Allocation Failure) [PSYoungGen: 141808K->10736K(141824K)] 211875K->188026K(320512K), 0.1829926 secs] [Times: user=1.02 sys=0.10, real=0.18 secs] 	
    2019-09-28T09:49:07.934-0800: [Full GC (Ergonomics) [PSYoungGen: 10736K->0K(141824K)] [ParOldGen: 177290K->171620K(402432K)] 188026K->171620K(544256K), [Metaspace: 3062K->3062K(1056768K)], 1.8672996 secs] [Times: user=5.96 sys=0.03, real=1.87 secs] 	
    2365	
    2019-09-28T09:49:09.832-0800: [GC (Allocation Failure) [PSYoungGen: 129254K->10738K(196608K)] 300875K->282609K(599040K), 0.1039307 secs] [Times: user=0.74 sys=0.07, real=0.10 secs] 	
    2019-09-28T09:49:09.936-0800: [Full GC (Ergonomics) [PSYoungGen: 10738K->0K(196608K)] [ParOldGen: 271871K->36047K(372736K)] 282609K->36047K(569344K), [Metaspace: 3067K->3067K(1056768K)], 0.4510440 secs] [Times: user=1.82 sys=0.01, real=0.45 secs] 	
    2019-09-28T09:49:10.440-0800: [GC (Allocation Failure) [PSYoungGen: 185856K->10752K(264704K)] 221903K->171359K(637440K), 0.1292143 secs] [Times: user=0.97 sys=0.01, real=0.12 secs] 	
    772

"狼哥，第一次Full GC果然耗时了1.87s，那我把堆调大看看，避免Full GC"

几分钟后...

"这次没有GC了，但是每次运行，前一个都比后一个耗时多点，这是怎么回事？"

"你试试放在不同线程中运行？"

"好"

又几分钟后...

"在不同线程中执行，两者耗时几乎一致，这是为什么？"

"你知道OSR吗？"

"不知道."

"那我跟你大概讲讲."

OSR(On-Stack Replacement )，是一种在运行时替换正在运行的函数/方法的栈帧的技术。

在现代的主流JVM中，都具备了多层编译的能力，一开始以解释的方式进行执行，这种性能相对来说（和c++比）会慢一点

但是一旦发现某一个函数执行很频繁的时候，就会采用JIT编译，提高函数执行性能（大部分比c++还快）。

但是，如果以函数为单位进行JIT编译，那么就无法应对main函数中包含循环体的情况，这个时候，OSR就派上了用场。

与其编译整个方法，我们可以在发现某个方法里有循环很热的时候，选择只编译方法里的某个循环，当循环体执行到 i = 5000 的时候，循环计数器达到了触发OSR编译的阈值，等编译完成之后，就可以执行编译后生成的代码。

所以在上面例子中，当我们第二次执行循环体的时候，已经在执行OSR编译后的代码，那么在性能上会比前一次会快那么一点点。

**END**

**如有收获，请划至底部，点击“在看”，谢****谢****！**

![640?wx\_fmt=png][640_wx_fmt_png]

欢迎长按下图关注公众号**石杉的架构笔记**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg 2]

**BAT架构经验倾囊相授**

[640_wx_fmt_jpeg]: /images/20230531/99a56c11604042359f56b56f094496b9.png
[640_wx_fmt_jpeg 1]: /images/20230531/cbe3b6c26d874dcfb5f7a154847cb1d0.png
[640_wx_fmt_png]: /images/20230531/a7db14a19ccb4059a45b8474e35b13a9.png
[640_wx_fmt_jpeg 2]: /images/20230531/2c96bb3d04c54ec0ba8fdc7355f919be.png