河南城市建设招标类网站,住房和城乡建设部网站 投诉,常州金坛网站建设,做SEO公司多给网站java8默认内存收集器大小对于软件至关重要。 很明显#xff0c;与大的整体方法相比#xff0c;在微服务体系结构中使用小片段具有更多优势。 最新的Java版本的Jigsaw有助于分解旧应用程序或从头开始构建新的云原生应用程序。 这种方法减少了磁盘空间#xff0c;构建时间和启… java8默认内存收集器 大小对于软件至关重要。 很明显与大的整体方法相比在微服务体系结构中使用小片段具有更多优势。 最新的Java版本的Jigsaw有助于分解旧应用程序或从头开始构建新的云原生应用程序。 这种方法减少了磁盘空间构建时间和启动时间。 但是它对RAM使用管理没有足够的帮助。 众所周知Java在许多情况下会消耗大量内存。 同时许多人还没有注意到Java在内存使用方面已经变得更加灵活并且提供了满足微服务需求的功能。 在本文中我们将分享我们的经验如何在Java进程中调整RAM的使用以使其更具弹性并获得更快的扩展和更低的总体拥有成本TCO的好处。 缩放有三个选项垂直水平和两者的组合。 为了最大化结果首先您需要以最佳方式设置垂直缩放。 然后当您的项目水平增长时单个容器内的预配置资源消耗将被复制到每个实例并且效率将成比例地增长。 如果配置正确则垂直缩放可完美地适用于微服务和整体组件并根据容器内的当前负载优化内存和CPU使用率。 选定的垃圾收集器是主要的基础砖之一其设置会影响整个项目。 OpenJDK有五种广泛使用的垃圾收集器解决方案 G1 平行 ConcMarkSweepCMS 序列号 雪兰多 让我们看看它们在缩放方面的表现以及可以应用哪些设置来改善结果。 为了进行测试我们将使用一个示例Java应用程序来帮助跟踪JVM垂直缩放结果 https : //github.com/jelastic/java-vertical-scaling-test 将为每个GC测试启动以下JVM启动选项 java -XX:Use[gc_name]GC -Xmx2g -Xms32m -jar app.jar [sleep] 哪里 [gc_name]将替换为特定的垃圾收集器类型 Xms是扩展步骤本例中为32 MB Xmx是最大缩放限制本例中为2 GB [sleep]是内存加载周期之间的间隔以毫秒为单位默认值为10 目前为了完全释放未使用的资源需要调用Full GC。 可以使用各种选项轻松启动它 jcmd pid GC.run –执行外部调用 System.gc() – 源代码内 jvisualvm –通过出色的VisualVM故障排除工具手动进行 -javaagent:agent.jar –可插入的常用方法。 Github repo Java Memory Agent上提供了开源自动化附件。 可以在输出日志中跟踪内存使用情况或使用VisualVM进行更深入的查看。 G1垃圾收集器 对于Java生态系统来说好消息是从JDK 9开始默认情况下启用了现代收缩的G1垃圾收集器。 如果使用较低版本的JDK则可以使用-XX:UseG1GC参数启用G1。 G1的主要优点之一是能够压缩可用的内存空间而无需花费较长的暂停时间和不提交未使用的堆的能力。 我们发现对于在OpenJDK或HotSpot JDK上运行的Java应用程序进行垂直扩展该GC是最佳选择。 为了更好地了解JVM在不同内存压力级别下的行为我们将运行以下三种情况1快速2中速和3内存使用量增长缓慢。 通过这种方式我们可以检查G1人机工程学的智能程度以及GC如何处理不同的内存使用动态。 内存使用量快速增长 java -XX:UseG1GC -Xmx2g -Xms32m -jar app.jar 0 内存在25秒内从32 MiB增长到1 GiB。 G1内存使用量快速增长 如果内存使用量的增长非常快则根据其内部自适应优化算法JVM人机工程学将忽略Xms扩展步骤并更快地保留RAM。 结果相对于实际使用量的快速增长蓝色我们看到了JVM橙色的RAM分配要快得多。 因此即使出现负载峰值使用G1还是安全的。 中等内存使用量增长 java -XX:UseG1GC -Xmx2g -Xms32m -jar app.jar 10 在4个周期内内存在90秒内从32 MiB增长到1 GiB。 有时为了使JVM符合人体工程学需要几个周期才能找到最佳的RAM分配算法。 G1中型内存使用量增长 如我们所见JVM在第4 个周期中对人体工程学进行了调整以使垂直扩展在可重复的周期中非常有效 内存使用量增长缓慢 java -XX:UseG1GC -Xmx2g -Xms32m -jar app.jar 100 内存从32 MiB增长到1 GiB增量时间增长了大约300秒。 非常灵活高效的资源扩展符合我们的期望-令人印象深刻。 G1内存使用量增长缓慢 如您所见橙色区域保留的RAM随着蓝色区域实际使用的增长而缓慢增加。 因此没有过量使用或不必要保留的内存。 重要提示激进堆或垂直缩放 用于提高Java应用程序性能的流行JVM配置通常会阻碍有效地垂直扩展的能力。 因此您需要在优先级之间选择对您的应用程序最重要的属性。 广泛使用的设置之一是激活积极堆以最大程度地利用堆的物理内存。 让我们分析一下使用此配置时发生的情况。 java -XX:UseG1GC -Xmx2g -Xms2g 要么 java -XX:UseG1GC -Xmx2g -XX:AggressiveHeap G1激进堆 如我们所见保留堆橙色是恒定的并且不会随时间变化因此容器中没有JVM的垂直缩放。 即使您的应用程序仅使用可用RAM的一小部分蓝色其余部分也不能与其他进程或其他容器共享因为它已完全分配给JVM。 因此如果要垂直扩展应用程序请确保未启用主动堆参数应为-XX:-AggressiveHeap 也不-XX:-AggressiveHeap -Xms定义为与-Xmx一样高例如不要声明-Xmx2g -Xms2g 。 并行垃圾收集器 并行是高吞吐量GC默认情况下在JDK8中使用。 同时它不适合进行内存缩减因此不适合进行灵活的垂直缩放。 为了确认这一点让我们对示例应用程序进行测试 java -XX:UseParallelGC -Xmx2g -Xms32m -jar app.jar 10 平行垃圾收集器 如我们所见未使用的RAM不会释放回OS。 带有并行GC的JVM可以永久保留它甚至不考虑显式的Full GC调用。 因此如果您希望根据应用程序负载从垂直缩放中受益请将Parallel更改为JDK中可用的收缩GC。 它将所有活动对象打包在一起删除垃圾对象然后取消提交未使用的内存并将其释放回操作系统。 串行和ConcMarkSweep垃圾收集器 Serial和ConcMarkSweep也在缩小垃圾回收器并且可以垂直扩展JVM中的内存使用量。 但是与G1相比它们需要4个完整的GC周期才能释放所有未使用的资源。 让我们看看这两个垃圾收集器的测试结果 java -XX:UseSerialGC -Xmx2g -Xms32m -jar app.jar 10 串行垃圾收集器 java -XX:UseConcMarkSweepGC -Xmx2g -Xms32m -jar app.jar 10 ConcMarkSweep垃圾收集器 从JDK9开始可以使用新的JVM选项-XX-ShrinkHeapInSteps加快内存释放速度该选项在第一个完整GC周期后立即减少已提交的RAM。 雪兰多亚垃圾收集器 Shenandoah是垃圾收集器中的一颗冉冉升起的新星该垃圾收集器已经被视为即将推出的针对JVM垂直扩展的最佳解决方案。 与其他版本相比主要的不同是能够异步收缩取消提交未使用的RAM并将其释放给OS而无需调用Full GC。 Shenandoah可以在检测到可用内存后立即压缩活动对象清理垃圾并将RAM释放回OS。 省略Full GC的可能性可以消除相关的性能下降。 让我们看看它在实践中如何工作 java -XX:UseShenandoahGC -Xmx2g -Xms32m -XX:UnlockExperimentalVMOptions -XX:ShenandoahUncommitDelay1000 -XX:ShenandoahGuaranteedGCInterval10000 -jar app.jar 10 在这里我们添加了雪南多厄可用的一些额外参数 -XX:UnlockExperimentalVMOptions –启用下面列出的uncommit选项所需 -XX:ShenandoahUncommitDelay1000 –垃圾收集器将开始取消提交超过此时间以毫秒为单位的未使用内存。 请注意当应用程序想要取回内存时将延迟设置得太低可能会导致分配停顿。 在实际部署中建议使延迟大于1秒 -XX:ShenandoahGuaranteedGCInterval10000 -这样可以保证在指定的时间间隔以毫秒为单位内的GC周期 雪兰多亚垃圾收集器 雪兰多Shenandoah非常灵活只分配必要的资源。 它还压缩了用过的RAM蓝色并即时将未消耗的保留RAM橙色释放回操作系统而无需进行昂贵的Full GC调用。 请注意此GC是试验性的因此您对稳定性的反馈将对其创建者有所帮助。 结论 Java会不断完善和适应不断变化的需求。 因此目前对于微服务和传统应用程序的云托管而言RAM的需求不再是问题因为已经有了适当的工具和方法来适当地对其进行扩展清理垃圾并释放所需进程的资源。 通过智能配置Java对于所有项目范围从云原生启动到传统企业应用程序都具有成本效益。 翻译自: https://www.javacodegeeks.com/2017/11/minimize-java-memory-usage-right-garbage-collector.htmljava8默认内存收集器
