在线教学网站建设在哪里可以做自己的网站

在线教学网站建设,在哪里可以做自己的网站,知名网站建设公司电话,wordpress浏览图片失败JVM性能调优案例-02-OOM案例02-OOM案例面试题OOM案例1#xff1a;堆溢出报错信息案例模拟JVM参数配置运行结果原因及解决方案dump文件分析gc日志分析OOM案例2#xff1a;元空间溢出元空间存储数据类型报错信息JVM参数配置案例模拟示例代码运行结果分析dump文件分析gc日志原因…JVM性能调优案例-02-OOM案例02-OOM案例面试题OOM案例1堆溢出报错信息案例模拟JVM参数配置运行结果原因及解决方案dump文件分析gc日志分析OOM案例2元空间溢出元空间存储数据类型报错信息JVM参数配置案例模拟示例代码运行结果分析dump文件分析gc日志原因及解决方案OOM案例3GC overhead limit exceeded案例模拟示例代码1示例代码2分析及解决第1步定位问题代码块第2步分析dump文件直方图第3步代码修改OOM案例4线程溢出报错信息问题原因案例模拟分析及解决解决方向1解决方向202-OOM案例面试题说到内存泄漏问有没有碰到内存泄漏怎么解决拼多多内存泄漏是怎么造成的拼多多、字节跳动如何理解内存泄漏问题有哪些情况会导致内存泄露如何解决 (阿里)OOM案例1堆溢出报错信息java.lang.OutOfMemoryError:Javaheap space案例模拟http://localhost:8080/add/** * 案例1模拟线上环境OOM */RequestMapping(/add)publicvoidaddObject(){System.err.println(addpeopleSevice);ArrayListPeoplepeoplenewArrayList();while(true){people.add(newPeople());}}DatapublicclassPeople{privateStringname;privateIntegerage;privateStringjob;privateStringsex;}JVM参数配置-XX:PrintGCDetails-XX:MetaspaceSize64m-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPathheap/heapdump.hprof-XX:PrintGCDateStamps-Xms50M-Xmx50M-Xloggc:log/gc-oomHeap.log运行结果Dumpingheaptoheap/heapdump.hprof...Heapdump file created[80005212bytes in1.440secs]2025-12-2115:11:40.643ERROR25564---[nio-8080-exec-1]o.a.c.c.C.[.[.[/].[dispatcherServlet]:Servlet.service()forservlet[dispatcherServlet]in contextwithpath[]threw exception[Handlerdispatch failed;nested exception isjava.lang.OutOfMemoryError:Javaheap space]withrootcausejava.lang.OutOfMemoryError:Javaheap space atjava.util.Arrays.copyOf(Arrays.java:3210)~[na:1.8.0_111]atjava.util.Arrays.copyOf(Arrays.java:3181)~[na:1.8.0_111]atjava.util.ArrayList.grow(ArrayList.java:261)~[na:1.8.0_111]atjava.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)~[na:1.8.0_111]atjava.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)~[na:1.8.0_111]atjava.util.ArrayList.add(ArrayList.java:458)~[na:1.8.0_111]atcom.atguigu.demo.controller.MemoryTestController.addObject(MemoryTestController.java:41)~[classes/:na]-XX:PrintGCDetails-XX:MetaspaceSize64m-Xss512K-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPathheap/heapdump3.hprof-XX:SurvivorRatio8-XX:PrintGCDateStamps-Xms80M-Xmx80M-Xloggc:log/gc-oom3.log原因及解决方案原因​ 1、代码中可能存在大对象分配​ 2、可能存在内存泄漏导致在多次GC之后还是无法找到一块足够大的内存容纳当前对象。解决方法​ 1、检查是否存在大对象的分配最有可能的是大数组分配​ 2、通过jmap命令把堆内存dump下来使用MAT等工具分析一下检查是否存在内存泄漏的问题​ 3、如果没有找到明显的内存泄漏使用 -Xmx 加大堆内存​ 4、还有一点容易被忽略检查是否有大量的自定义的 Finalizable 对象也有可能是框架内部提供的考虑其存在的必要性dump文件分析gc日志分析在线分析gc日志https://gceasy.io/OOM案例2元空间溢出元空间存储数据类型方法区Method Area与 Java 堆一样是各个线程共享的内存区域它用于存储已被虚拟机加载的类信息、常量、即时编译器编译后的代码等数据。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分但是它却有一个别名叫做 Non-Heap非堆目的应该是与 Java 堆区分开来。​Java 虚拟机规范对方法区的限制非常宽松除了和 Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外还可以选择不实现垃圾收集。垃圾收集行为在这个区域是比较少出现的其内存回收目标主要是针对常量池的回收和对类型的卸载。当方法区无法满足内存分配需求时将抛出 OutOfMemoryError 异常。报错信息java.lang.OutOfMemoryError:MetaspaceJVM参数配置-XX:PrintGCDetails-XX:MetaspaceSize60m-XX:MaxMetaspaceSize60m-Xss512K-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPathheap/heapdumpMeta.hprof-XX:SurvivorRatio8-XX:TraceClassLoading-XX:TraceClassUnloading-XX:PrintGCDateStamps-Xms60M-Xmx60M-Xloggc:log/gc-oomMeta.log案例模拟http://localhost:8080/metaSpaceOom示例代码/** * 案例2:模拟元空间OOM溢出 */RequestMapping(/metaSpaceOom)publicvoidmetaSpaceOom(){ClassLoadingMXBeanclassLoadingMXBeanManagementFactory.getClassLoadingMXBean();while(true){EnhancerenhancernewEnhancer();enhancer.setSuperclass(People.class);enhancer.setUseCache(false);// enhancer.setUseCache(true);enhancer.setCallback((MethodInterceptor)(o,method,objects,methodProxy)-{System.out.println(我是加强类输出print之前的加强方法);returnmethodProxy.invokeSuper(o,objects);});Peoplepeople(People)enhancer.create();people.print();System.out.println(people.getClass());System.out.println(totalClass:classLoadingMXBean.getTotalLoadedClassCount());System.out.println(activeClass:classLoadingMXBean.getLoadedClassCount());System.out.println(unloadedClass:classLoadingMXBean.getUnloadedClassCount());}}运行结果分析dump文件分析gc日志有大量的full gcMeta Space 峰值接近已分配值40 MB vs 37.76 MB→ 元空间几乎满载可能需要关注类加载数量或反射频繁使用。整体来看堆空间使用率适中但元空间压力稍高原因及解决方案JDK8后元空间替换了永久代元空间使用的是本地内存原因运行期间生成了大量的代理类导致方法区被撑爆无法卸载应用长时间运行没有重启元空间内存设置过小解决方法因为该 OOM 原因比较简单解决方法有如下几种检查是否永久代空间或者元空间设置的过小检查代码中是否存在大量的反射操作dump之后通过mat检查是否存在大量由于反射生成的代理类OOM案例3GC overhead limit exceeded案例模拟示例代码1publicstaticvoidtest1(){inti0;ListStringlistnewArrayList();try{while(true){list.add(UUID.randomUUID().toString().intern());i;}}catch(Throwablee){System.out.println(************i: i);e.printStackTrace();throwe;}}JVM配置-XX:PrintGCDetails-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPathheap/dumpExceeded.hprof-XX:PrintGCDateStamps-Xms10M-Xmx10M-Xloggc:log/gc-oomExceeded.log报错信息[FullGC(Ergonomics)[PSYoungGen:2047K-2047K(2560K)][ParOldGen:7110K-7095K(7168K)]9158K-9143K(9728K),[Metaspace:3177K-3177K(1056768K)],0.0479640secs][Times:user0.23sys0.01,real0.05secs]java.lang.OutOfMemoryError:GC overhead limit exceeded[FullGC(Ergonomics)[PSYoungGen:2047K-2047K(2560K)][ParOldGen:7114K-7096K(7168K)]9162K-9144K(9728K),[Metaspace:3198K-3198K(1056768K)],0.0408506secs][Times:user0.22sys0.01,real0.04secs]通过查看GC日志可以发现系统在频繁性的做FULL GC但是却没有回收掉多少空间那么引起的原因可能是因为内存不足也可能是存在内存泄漏的情况接下来我们要根据堆dump文件来具体分析。示例代码2publicstaticvoidtest2(){Stringstr;Integeri1;try{while(true){i;strUUID.randomUUID();}}catch(Throwablee){System.out.println(************i: i);e.printStackTrace();throwe;}}JVM配置-XX:PrintGCDetails-XX:HeapDumpOnOutOfMemoryError-XX:HeapDumpPathheap/dumpHeap1.hprof-XX:PrintGCDateStamps-Xms10M-Xmx10M-Xloggc:log/gc-oomHeap1.log报错信息分析及解决第1步定位问题代码块第2步分析dump文件直方图看到发生OOM是因为进行了死循环不停的往 ArrayList 存放字符串常量JDK1.8以后字符串常量池移到了堆中存储所以最终导致内存不足发生了OOM。打开Histogram可以看到String类型的字符串占用了大概8M的空间几乎把堆占满但是还没有占满所以这也符合Sun 官方对此的定义超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常本质是一个预判性的异常抛出该异常时系统没有真正的内存溢出。第3步代码修改根据业务来修改是否需要死循环。原因这个是JDK6新加的错误类型一般都是堆太小导致的。Sun 官方对此的定义超过98%的时间用来做GC并且回收了不到2%的堆内存时会抛出此异常。本质是一个预判性的异常抛出该异常时系统没有真正的内存溢出解决方法检查项目中是否有大量的死循环或有使用大内存的代码优化代码。添加参数-XX:-UseGCOverheadLimit禁用这个检查其实这个参数解决不了内存问题只是把错误的信息延后最终出现 java.lang.OutOfMemoryError: Java heap space。dump内存检查是否存在内存泄漏如果没有加大内存。OOM案例4线程溢出报错信息java.lang.OutOfMemoryError:unabletocreatenewnativeThread问题原因出现这种异常基本上都是创建了大量的线程导致的案例模拟操作系统会崩溃linux无法再进行任何命令mac/windows可能直接关机重启。鉴于以上原因我们在虚拟机进行测试。/** * 测试4线程溢出 * author shkstart * create 17:45 */publicclassTestNativeOutOfMemoryError{publicstaticvoidmain(String[]args){for(inti0;;i){System.out.println(i i);newThread(newHoldThread()).start();}}}classHoldThreadextendsThread{CountDownLatchcdlnewCountDownLatch(1);Overridepublicvoidrun(){try{cdl.await();}catch(InterruptedExceptione){}}}运行结果i15241Exceptionin threadmainjava.lang.OutOfMemoryError:unabletocreatenewnativethread atjava.lang.Thread.start0(NativeMethod)atjava.lang.Thread.start(Thread.java:717)atTestNativeOutOfMemoryError.main(TestNativeOutOfMemoryError.java:9)分析及解决解决方向1通过 -Xss 设置每个线程栈大小的容量JDK5.0以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。正常情况下在相同物理内存下减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的,不能无限生成,经验值在3000~5000左右。能创建的线程数的具体计算公式如下(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) Number of threads——————————————————————————————————————MaxProcessMemory 指的是进程可寻址的最大空间JVMMemory JVM内存ReservedOsMemory 保留的操作系统内存ThreadStackSize 线程栈的大小——————————————————————————————————————在Java语言里 当你创建一个线程的时候虚拟机会在JVM内存创建一个Thread对象同时创建一个操作系统线程而这个系统线程的内存用的不是JVMMemory而是系统中剩下的内存(MaxProcessMemory - JVMMemory - ReservedOsMemory)。由公式得出结论你给JVM内存越多那么你能创建的线程越少越容易发生java.lang.OutOfMemoryError: unable to create new native thread问题解决1、 如果程序中有bug导致创建大量不需要的线程或者线程没有及时回收那么必须解决这个bug修改参数是不能解决问题的。2、 如果程序确实需要大量的线程现有的设置不能达到要求那么可以通过修改MaxProcessMemoryJVMMemoryThreadStackSize这三个因素来增加能创建的线程数。3、 MaxProcessMemory 使用64位操作系统4、JVMMemory 减少JVMMemory的分配5、ThreadStackSize 减小单个线程的栈大小经实测在32位windows系统下较为严格遵守64位系统下只能保证正/负相关性甚至说相关性也不能保证。即​在测试的过程中64位操作系统下调整Xss的大小并没有对产生线程的总数产生影响程序执行到极限的时候操作系统会死机。无法看出效果在32位win7操作系统下测试jdk版本1.8适配32位操作系统会发现调整Xss的大小会对线程数量有影响如下表所示由上可见64位操作系统对于实验的结果是不明显的但是32位操作系统对于Xss的设置对于实验结果是明显的为什么会产生这样的结果我们上面讲到过线程数量的计算公式(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) Number of threads其中MaxProcessMemory表示最大寻址空间在32位系统中CPU的“寻址范围”就受到32个二进制位的限制也就是说假设它要访问内存它的能力是只能访问4G内存。32位二进制数最大值是11111111 11111111 11111111 11111111b2的32次方 4294967296 4194304k(1k是1024) 4096M(1M是1048576) 4GB。也就是说32位CPU只能访问4GB的内存。再减去显卡上的显存等内存可用内存要小于4G所以32位操作系统可用线程数量是有限的。64位二进制数的最大值是11111111 11111111 11111111 11111111 11111111 11111111 11111111 11111111b2的64次方 17179869184 GB大家可以看看64位操作的寻址空间大小比32位操作系统多了太多所以这也是为什么我们总是无法测试出很好效果的原因。综上在生产环境下如果需要更多的线程数量建议使用64位操作系统如果必须使用32位操作系统可以通过调整Xss的大小来控制线程数量。解决方向2线程总数也受到系统空闲内存和操作系统的限制检查是否该系统下有此限制/proc/sys/kernel/pid_max 系统最大pid值在大型系统里可适当调大/proc/sys/kernel/threads-max 系统允许的最大线程数maxuserprocessulimit -u 系统限制某用户下最多可以运行多少进程或线程/proc/sys/vm/max_map_countmax_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量。虚拟内存区域是一个连续的虚拟地址空间区域。在进程的生命周期中每当程序尝试在内存中映射文件链接到共享内存段或者分配堆空间的时候这些区域将被创建。调优这个值将限制进程可拥有VMA的数量。限制一个进程拥有VMA的总数可能导致应用程序出错因为当进程达到了VMA上线但又只能释放少量的内存给其他的内核进程使用时操作系统会抛出内存不足的错误。如果你的操作系统在NORMAL区域仅占用少量的内存那么调低这个值可以帮助释放内存给内核用。真实测试发现 当我们增大了threads-max参数时比如扩大10倍echo 157010 /proc/sys/kernel/threads-max运行相关程序发现可创建的线程数确实扩大了。但是仍受相关因素的影响不能保证创建的线程数也扩大对应的倍数。要想创建更多线程会发现在执行完程序报错的log日志(自动在当前目录下生成)中有说明