• JVM学习笔记-从底层了解程序运行(二)


    解决JVM运行中的问题
        一个案例理解常用工具
            测试代码:
            /**
             * 从数据库中读取信用数据,套用模型,并把结果进行记录和传输
             */
            
            public class T15_FullGC_Problem01 {
            
                private static class CardInfo {
                    BigDecimal price = new BigDecimal(0.0);
                    String name = "张三";
                    int age = 5;
                    Date birthdate = new Date();
            
                    public void m() {}
                }
            
                private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,
                        new ThreadPoolExecutor.DiscardOldestPolicy());
            
                public static void main(String[] args) throws Exception {
                    executor.setMaximumPoolSize(50);
            
                    for (;;){
                        modelFit();
                        Thread.sleep(100);
                    }
                }
            
                private static void modelFit(){
                    List<CardInfo> taskList = getAllCardInfo();
                    taskList.forEach(info -> {
                        // do something
                        executor.scheduleWithFixedDelay(() -> {
                            //do sth with info
                            info.m();
            
                        }, 2, 3, TimeUnit.SECONDS);
                    });
                }
            
                private static List<CardInfo> getAllCardInfo(){
                    List<CardInfo> taskList = new ArrayList<>();
            
                    for (int i = 0; i < 100; i++) {
                        CardInfo ci = new CardInfo();
                        taskList.add(ci);
                    }
            
                    return taskList;
                }
            }
        java -Xms200M -Xmx200M -XX:+PrintGC com.mashibing.jvm.gc.T15_FullGC_Problem01
        一般是运维团队首先受到报警信息(CPU Memory)
        top命令观察到问题:内存不断增长 CPU占用率居高不下
        top -Hp +pid观察进程中的线程,哪个线程CPU和内存占比高
        jps定位具体java进程 
        jstack 定位线程状况,重点关注:WAITING BLOCKED jstack +PID
        
    
    

              eg. 

             waiting on condition [0xe7f5a000]  (a java.lang.Object) 假如有一个进程中100个线程,很多线程都在waiting on <xx> ,
            一定要找到是哪个线程持有这把锁 
       
    
    

             怎么找?搜索jstack dump的信息,找<xx> ,看哪个线程持有这把锁RUNNABLE 

            作业:1:写一个死锁程序,用jstack观察 
            2 :写一个程序,一个线程持有锁不释放,其他线程等待
        为什么阿里规范里规定,线程的名称(尤其是线程池)都要写有意义的名称 
            怎么样自定义线程池里的线程名称?(自定义ThreadFactory)
        jinfo pid  查询虚拟机信息
        
    
    

         jstat -gc 动态观察gc情况 / 阅读GC日志发现频繁GC / arthas观察 / jconsole/jvisualVM/ Jprofiler(最好用) jstat -gc 4655 500

        
    
    

         每个500个毫秒打印GC的情况 如果面试官问你是怎么定位OOM问题的?如果你回答用图形界面(错误) 

    1:已经上线的系统不用图形界面用什么?(cmdline arthas) 
        2:图形界面到底用在什么地方?测试!测试的时候进行监控!(压测观察)
        jmap - histo 4655 | head -20,查找有多少对象产生
        
    
    

         jmap -dump:format=b,file=xxx pid 1361

        -XX:HeapDumpPath=/x/x  配置jvm启动参数也可以dump 堆文件

    线上系统,内存特别大,jmap -demp执行期间会对进程产生很大影响,甚至卡顿(电商不适合) 
            1:设定了参数HeapDump,OOM的时候会自动产生堆转储文件 
            2:很多服务器备份(高可用),停掉这台服务器对其他服务器不影响 
            3:在线定位(一般小点儿公司用不到)
        java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError T15_FullGC_Problem01
        使用MAT / jhat /jvisualvm 进行dump文件分析 https://www.cnblogs.com/baihuitestsoftware/articles/6406271.html 
            jhat -J-mx512M xxx.dump http://192.168.17.11:7000 
            拉到最后:找到对应链接 可以使用OQL查找特定问题对象
        找到代码的问题
        问题分析流程: 慢,CPU飙高->top->Jps->Jstack->Jmap
        jconsole远程连接
                程序启动加入参数:
    java -Djava.rmi.server.hostname=192.168.65.10 -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=11111 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -XX:+PrintGC -Xms200M -Xmx200M T15_FullGC_Problem01
                如果遭遇 Local host name unknown:XXX的错误,修改/etc/hosts文件,把XXX加入进去
    192.168.65.10 basic localhost localhost.localdomain localhost4 localhost4.localdomain4
    ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
                关闭linux防火墙(实战中应该打开对应端口)
    service iptables stop
    chkconfig iptables off #永久关闭
            windows上打开 jconsole远程连接 192.168.17.11:11111
       
    
    

         jvisualvm远程连接

            https://www.cnblogs.com/liugh/p/7620336.html (简单做法)
       
        arthas在线排查工具
                § 启动arthas java -jar arthas-boot.jar
                § 绑定java进程
                § dashboard命令观察系统整体情况
                § help 查看帮助
                § help xx 查看具体命令帮助
                § https://www.jianshu.com/p/507f7e0cc3a3 
            

             为什么需要在线排查? 

                在生产上我们经常会碰到一些不好排查的问题,例如线程安全问题,用最简单的threaddump或者 heapdump不好查到问题原因。为了排查这些问题,有时我们会临时加一些日志,比如在一些关键的函数里打印出入参,然后重新打包发布,如果打了日志还是没找到问题,继续加日志,重新打包发布。对于上线流程复杂而且审核比较严的公司,从改代码到上线需要层层的流转,会大大影响问题排查的进度。 
            jvm观察jvm信息
            thread定位线程问题 thread + ID
            
    
    

             dashboard 观察系统情况

            

             heapdump + jhat分析  完成之后ip+7000端口访问

            
    
    

             jad反编译 

                动态代理生成类的问题定位 
                第三方的类(观察代码) 
                版本问题(确定自己最新提交的版本是不是被使用)
            
    
    

             redefine 热替换 

                目前有些限制条件:只能改方法实现(方法已经运行完成),不能改方法名, 不能改属性 m() -> mm()
                直接线上修改源文件方法内容,完成后重新编译,最后redefine重新替换
            
    
    

             sc - search class

            watch - watch method
            没有包含的功能:jmap
        案例汇总
        OOM产生的原因多种多样,有些程序未必产生OOM,不断FGC(CPU飙高,但内存回收特别少) (上面案例)
            1. 硬件升级系统反而卡顿的问题(见上)
            2. 线程池不当运用产生OOM问题(见上) 不断的往List里加对象(实在太LOW)
            3. smile jira问题 
                实际系统不断重启 
                解决问题 加内存 + 更换垃圾回收器 G1 
                真正问题在哪儿?不知道
            4. tomcat http-header-size过大问题(Hector)
            5. lambda表达式导致方法区溢出问题(MethodArea / Perm Metaspace) 
                LambdaGC.java -XX:MaxMetaspaceSize=9M -XX:+PrintGCDetails
            6. 直接内存溢出问题(少见) 
                《深入理解Java虚拟机》P59,使用Unsafe分配直接内存,或者使用NIO的问题
            7. 栈溢出问题 
                -Xss设定太小
            8. 比较一下这两段程序的异同,分析哪一个是更优的写法:
    Object o = null;
    for(int i=0; i<100; i++) {
       o = new Object();
       //业务处理
    }
    for(int i=0; i<100; i++) {
       Object o = new Object();
    }
            9. 重写finalize引发频繁GC 
                小米云,HBase同步系统,系统通过nginx访问超时报警,最后排查,C++程序员重写finalize引发频繁GC问题 
                为什么C++程序员会重写finalize?(new 析构函数 delete) finalize耗时比较长(200ms)
            10. 如果有一个系统,内存一直消耗不超过10%,但是观察GC日志,发现FGC总是频繁产生,会是什么引起的? 
                System.gc() (这个比较Low)
            11. Distuptor有个可以设置链的长度,如果过大,然后对象大,消费完不主动释放,会溢出 (来自 死物风情)
            12. 用jvm都会溢出,mycat用崩过,1.6.5某个临时版本解析sql子查询算法有问题,9个exists的联合sql就导致生成几百万的对象(来自 死物风情)
            13. new 大量线程,会产生 native thread OOM,(low)应该用线程池, 
                解决方案:减少堆空间(太TMlow了),预留更多内存产生native thread 
                JVM内存占物理内存比例 50% - 80%
            
            
        
    G1详解
        特点:
            并发收集
            压缩空闲空间不会延长GC的暂停时间;
            更易预测的GC暂停时间;
            适用不需要实现很高的吞吐量的场景
        分区:
            ○ 每个分区都可能是年轻代也可能是老年代,但是在同一时刻只能属于某个代。
            ○ 年轻代、幸存区、老年代这些概念还存在,成为逻辑上的概念,这样方便复用之前分代框架的逻辑。在物理上不需要连续,则带来了额外的好处一有 的分区内垃圾对象特别多,有的分区内垃圾对象很少,G1会优先回收垃圾对象特别多的分区,这样可以花费较少的时间来回收这些分区的垃圾,这也就是G1名字的由来,即首先收集垃圾最多的分区。
            ○ 新生代其实并不是适用于这种算法的,依然是在新生代满了的时候,对整个新生代进行回收一整个新生代中的对象,要么被回收、要么晋升,至于新生代也采取分区机制的原因,则是因为这样跟老年代的策略统一, 方便调整代的大小.
            ○ G1还是一种带 压缩的收集器,在回收老年代的分区时, 是将存活的对象从一个分区拷贝到另一个可用分区,这个拷贝的过程就实现了局部的压缩。每个分区的大小从1M到,32M不等,但是都是2的冥次方。
            ○ G1的内存区域不是固定的E或者O,肯在这个阶段是E,在另一个阶段又是O
        Card Table 
            由于做YGC时,需要扫描整个OLD区,效率非常低,所以JVM设计了CardTable, 
            如果一个OLD区CardTable中有对象指向Y区,就将它设为Dirty,下次扫描时,
            只需要扫描Dirty Card 在结构上,Card Table用BitMap来实现
            
    
    

         CSet(Collection Set)

            一组可被回收的分区的集合。
            在CSet中存活的数据会在GC过程中被移动到另一个可用分区,
            CSet中的分区可以来自Eden空间、survivor空间、 或者老年代。
            CSet会占用不到整个堆空间的1%大小。
        RSet (RememberedSet)
            记录了其他Region中的对象到本Region的引用
            RSet的价值在于
            使得垃圾收集器不需要扫描整个堆找到谁引用了当前分区中的对象,只需要扫描RSet即可。        
    每个region有多大
            取值范围: 1 2 4 8 16 32                          
        humongous object
            超过单个region的50%
            跨越多个region
            
    
    

         G1 GC何时触发

            YGC
                Eden空间不足
                多线程并行执行
            FGC 
                Old空间不足
                System.gc()
            MixedGC(类似CMS)
                XX:InitiatingHeapOccupacyPercent
                    默认值45%
                    当0超过这个值时,启动MixedGC
        MixedGC的过程
            初始标记STW
            并发标记
            最终标记STW (重新标记)
            筛选回收STW (并行) 
        三色标记算法 并发阶段标记算法    (三色标记,颜色指针)
            并发标记算法难点:在标记过程中,对象引用关系正在发生改变(浮动垃圾)
            三色标记法
                定义:
                    白色:未被标记的对象
                    灰色:自身被标记,成员变量未被标记
                    黑色:自身和成员变量均已标记完成
                漏标
                    在remark过程中,黑色指向了白色,如果不对黑色重新扫描,则会漏标
                    会把白色D对象当做没有新引用指向从而回收掉并发标记过程中,Mutator删除 了
                    所有从灰色到白色的引用,会产生漏标此时白色对象应该被回收
                漏标案例:
                    A(黑):自己已经标记,fields 都标记完成
                    B(灰):自己标记完成,还没来得及标记fields
                    C(灰):自己标记完成,还没来得及标记fields
                    D(白):没有遍历到的节点
                产生漏标:
                    1.标记进行时增加了一个黑到白的引用,如果不重新对黑色进行处理,则会漏标
                    2.标记进行时删除了灰对象到白对象的引用,那么这个白对象有可能被漏标
                解决漏标:
                    打破以下两个条件之一即可
                    1. incremental update增量更新,关注引用的增加,
                    把黑色重新标记为灰色,下次重新扫描属性
                    2. SATB (snapshot at the beginning)-关注引用的删除
                    当B->D消失时,要把这个引用推到GC的堆栈,保证D还能被GC描到
                    CMS用第一种,G1用第二种
                为什么G1用SATB?
                    □ 灰色-->白色引用消失时,如果没有黑色指向白色引用会被push到堆栈
                    □ 下次扫描时拿到这个引用,由于有RSet的存在,不需要扫描整个堆去查找指向白色的引用,效率比较高
                    □ SATB配合RSet,浑然天成
        为什么选择G1
            ○ 追求吞吐量
                § 100 cpu 
                § 99 app 1 GC
                § 吞吐量= 99%
            ○ 追求响应时间
                § - XX:MaxGCPauseMillis 200
                § 对STW进行控制
            ○ 灵活
                § 分Region回收
                § 优先回收花费时间少、垃圾比例高的Region
                
    GC常用参数
        • -Xmn -Xms -Xmx -Xss 
            ○ 年轻代 初始堆 最大堆 栈空间
        • -XX:+UseTLAB 
            ○ 使用TLAB,默认打开
        • -XX:+PrintTLAB 
            ○ 打印TLAB的使用情况
        • -XX:TLABSize 
            ○ 设置TLAB大小
        • -XX:+DisableExplictGC 
            ○ System.gc()不管用 ,FGC
        • -XX:+PrintGC
        • -XX:+PrintGCDetails
        • -XX:+PrintHeapAtGC
        • -XX:+PrintGCTimeStamps
        • -XX:+PrintGCApplicationConcurrentTime (低) 
            ○ 打印应用程序时间
        • -XX:+PrintGCApplicationStoppedTime (低) 
            ○ 打印暂停时长
        • -XX:+PrintReferenceGC (重要性低) 
            ○ 记录回收了多少种不同引用类型的引用
        • -verbose:class 
            ○ 类加载详细过程
        • -XX:+PrintVMOptions
        • -XX:+PrintFlagsFinal -XX:+PrintFlagsInitial 
            ○ 必须会用
        • -Xloggc:opt/log/gc.log
        • -XX:MaxTenuringThreshold 
            ○ 升代年龄,最大值15
        • 锁自旋次数 -XX:PreBlockSpin 热点代码检测参数-XX:CompileThreshold 逃逸分析 标量替换 ... 
            ○ 这些不建议设置
    Parallel常用参数
        • -XX:SurvivorRatio
        • -XX:PreTenureSizeThreshold 
            ○ 大对象到底多大
        • -XX:MaxTenuringThreshold
        • -XX:+ParallelGCThreads 
            ○ 并行收集器的线程数,同样适用于CMS,一般设为和CPU核数相同
        • -XX:+UseAdaptiveSizePolicy 
            ○ 自动选择各区大小比例
    CMS常用参数
        • -XX:+UseConcMarkSweepGC
        • -XX:ParallelCMSThreads 
            ○ CMS线程数量
        • -XX:CMSInitiatingOccupancyFraction 
            ○ 使用多少比例的老年代后开始CMS收集,默认是68%(近似值),如果频繁发生SerialOld卡顿,应该调小,(频繁CMS回收)
        • -XX:+UseCMSCompactAtFullCollection 
            ○ 在FGC时进行压缩
        • -XX:CMSFullGCsBeforeCompaction 
            ○ 多少次FGC之后进行压缩
        • -XX:+CMSClassUnloadingEnabled
        • -XX:CMSInitiatingPermOccupancyFraction 
            ○ 达到什么比例时进行Perm回收
        • GCTimeRatio 
            ○ 设置GC时间占用程序运行时间的百分比
        • -XX:MaxGCPauseMillis 
            ○ 停顿时间,是一个建议时间,GC会尝试用各种手段达到这个时间,比如减小年轻代
    G1常用参数
        • -XX:+UseG1GC
        • -XX:MaxGCPauseMillis 
            ○ 建议值,G1会尝试调整Young区的块数来达到这个值
        • -XX:GCPauseIntervalMillis 
            ○ GC的间隔时间
        • -XX:+G1HeapRegionSize 
            ○ 分区大小,建议逐渐增大该值,1 2 4 8 16 32。 随着size增加,垃圾的存活时间更长,GC间隔更长,但每次GC的时间也会更长 ZGC做了改进(动态区块大小)
        • G1NewSizePercent 
            ○ 新生代最小比例,默认为5%
        • G1MaxNewSizePercent 
            ○ 新生代最大比例,默认为60%
        • GCTimeRatio 
            ○ GC时间建议比例,G1会根据这个值调整堆空间
        • ConcGCThreads 
            ○ 线程数量
        • InitiatingHeapOccupancyPercent 
            ○ 启动G1的堆空间占用比例
    练习题
        1. -XX:MaxTenuringThreshold控制的是什么? 
            A: 对象升入老年代的年龄 
            B: 老年代触发FGC时的内存垃圾比例
        2. 生产环境中,倾向于将最大堆内存和最小堆内存设置为:(为什么?)
            A: 相同 
            B:不同
        3. JDK1.8默认的垃圾回收器是: 
            A: ParNew + CMS 
            B: G1 
            C: PS + ParallelOld 
            D: 以上都不是
        4. 什么是响应时间优先?
        5. 什么是吞吐量优先?
        6. ParNew和PS的区别是什么?
        7. ParNew和ParallelOld的区别是什么?(年代不同,算法不同)
        8. 长时间计算的场景应该选择:A:停顿时间 B: 吞吐量
        9. 大规模电商网站应该选择:A:停顿时间 B: 吞吐量
        10. HotSpot的垃圾收集器最常用有哪些?
        11. 常见的HotSpot垃圾收集器组合有哪些?
        12. JDK1.7 1.8 1.9的默认垃圾回收器是什么?如何查看?
        13. 所谓调优,到底是在调什么?
        14. 如果采用PS + ParrallelOld组合,怎么做才能让系统基本不产生FGC
        15. 如果采用ParNew + CMS组合,怎样做才能够让系统基本不产生FGC
    1.加大JVM内存
    2.加大Young的比例
    3.提高Y-O的年龄
    4.提高S区比例
    5.避免代码内存泄漏
        16. G1是否分代?G1垃圾回收器会产生FGC吗?
        17. 如果G1产生FGC,你应该做什么?
            1. 扩内存
            2. 提高CPU性能(回收的快,业务逻辑产生对象的速度固定,垃圾回收越快,内存空间越大)
            3. 降低MixedGC触发的阈值,让MixedGC提早发生(默认是45%18. 问:生产环境中能够随随便便的dump吗? 
            1. 小堆影响不大,大堆会有服务暂停或卡顿(加live可以缓解),dump前会有FGC
        19. 问:常见的OOM问题有哪些? 
            1. 栈 堆 MethodArea 直接内存
    参考资料:
        1. https://blogs.oracle.com/jonthecollector/our-collectors
        2. https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
        3. http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
        4. JVM调优参考文档:https://docs.oracle.com/en/java/javase/13/gctuning/introduction-garbage-collection-tuning.html#GUID-8A443184-7E07-4B71-9777-4F12947C8184 
        5. https://www.cnblogs.com/nxlhero/p/11660854.html 在线排查工具
        6. https://www.jianshu.com/p/507f7e0cc3a3 arthas常用命令
        7. Arthas手册:
            1. 启动arthas java -jar arthas-boot.jar
            2. 绑定java进程
            3. dashboard命令观察系统整体情况
            4. help 查看帮助
            5. help xx 查看具体命令帮助
        8. jmap命令参考: https://www.jianshu.com/p/507f7e0cc3a3 
            1. jmap -heap pid
            2. jmap -histo pid
            3. jmap -clstats pid

    CMS日志分析

    执行命令:java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC T15_FullGC_Problem01

    [GC (Allocation Failure) [ParNew: 6144K->640K(6144K), 0.0265885 secs] 6585K->2770K(19840K), 0.0268035 secs] [Times: user=0.02 sys=0.00, real=0.02 secs]

    ParNew:年轻代收集器

    6144->640:收集前后的对比

    6144):整个年轻代容量

    6585 -> 2770:整个堆的情况

    19840):整个堆大小

    [GC (CMS Initial Mark) [1 CMS-initial-mark: 7350K(13696K)] 9033K(19840K), 0.0018277 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

    //7350K(13696K) : 老年代使用(最大)

    //9033K(19840K) : 整个堆使用(最大)

    [CMS-concurrent-mark-start]

    [CMS-concurrent-mark: 0.012/0.012 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

    //这里的时间意义不大,因为是并发执行

    [CMS-concurrent-preclean-start]

    [CMS-concurrent-preclean: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

    //标记CardDirty,也称为Card Marking

    [GC (CMS Final Remark) [YG occupancy: 1682 K (6144 K)][Rescan (parallel) , 0.0015702 secs][weak refs processing, 0.0000247 secs][class unloading, 0.0004549 secs][scrub symbol table, 0.0006202 secs][scrub string table, 0.0000321 secs][1 CMS-remark: 7350K(13696K)] 9033K(19840K), 0.0028101 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

    //STW阶段,YG occupancy:年轻代占用及容量

    //[Rescan (parallel)STW下的存活对象标记

    //weak refs processing: 弱引用处理

    //class unloading: 卸载用不到的class

    //scrub symbol(string) table:

    //cleaning up symbol and string tables which hold class-level metadata and

    //internalized string respectively

    //CMS-remark: 8511K(13696K): 阶段过后的老年代占用及容量

    //10108K(19840K): 阶段过后的堆占用及容量

    [CMS-concurrent-sweep-start]

    [CMS-concurrent-sweep: 0.004/0.004 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

    //标记已经完成,进行并发清理

    [CMS-concurrent-reset-start]

    [CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

    //重置内部结构,为下次GC做准备

    G1日志详解

    执行命令:java -Xms20M -Xmx20M -XX:+PrintGCDetails -XX:+UseG1GC T15_FullGC_Problem01

    [GC pause (G1 Evacuation Pause) (young), 0.0016743 secs]

    //young -> 年轻代 Evacuation-> 复制存活对象

    //initial-mark 混合回收的阶段,这里是YGC混合老年代回收

       [Parallel Time: 1.6 ms, GC Workers: 1]//一个GC线程

          [GC Worker Start (ms):  105.0]

          [Ext Root Scanning (ms):  0.6]

          [Update RS (ms):  0.0]

             [Processed Buffers:  0]

          [Scan RS (ms):  0.0]

          [Code Root Scanning (ms):  0.0]

          [Object Copy (ms):  0.7]

          [Termination (ms):  0.0]

             [Termination Attempts:  1]

          [GC Worker Other (ms):  0.0]

          [GC Worker Total (ms):  1.4]

          [GC Worker End (ms):  106.4]

       [Code Root Fixup: 0.0 ms]

       [Code Root Purge: 0.0 ms]

       [Clear CT: 0.0 ms]

       [Other: 0.1 ms]

          [Choose CSet: 0.0 ms]

          [Ref Proc: 0.0 ms]

          [Ref Enq: 0.0 ms]

          [Redirty Cards: 0.0 ms]

          [Humongous Register: 0.0 ms]

          [Humongous Reclaim: 0.0 ms]

          [Free CSet: 0.0 ms]

       [Eden: 3072.0K(3072.0K)->0.0B(3072.0K) Survivors: 0.0B->1024.0K Heap: 3072.0K(20.0M)->496.1K(20.0M)]

     [Times: user=0.00 sys=0.00, real=0.00 secs]

    //以下是混合回收其他阶段

    [GC concurrent-root-region-scan-start]

    [GC concurrent-root-region-scan-end, 0.0000062 secs]

    [GC concurrent-mark-start]

    //无法evacuation,进行FGC

    [Full GC (Allocation Failure)  18M->18M(20M), 0.0591118 secs]

       [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 18.8M(20.0M)->18.8M(20.0M)], [Metaspace: 2456K->2456K(4400K)]

     [Times: user=0.06 sys=0.00, real=0.06 secs]

  • 相关阅读:
    关于jqGrid组件数据显示不出问题
    jq修改导航栏样式(选中、使用两张图片替代的是否选中效果)
    jq获取图片并转换为base64
    jq怎么给图片绑定上传文件按钮
    ajax上传文件
    layui超链接追加tab选项卡必须手动刷新才出现问题
    thinkphp5中使用excel导出数据表格(包涵图片)
    关于php条形码生成(barcode),修改样式
    php中对象赋值问题
    数组小工具2
  • 原文地址:https://www.cnblogs.com/hikoukay/p/12829127.html
Copyright © 2020-2023  润新知