毕业设计 网站建设选题,福州免费建站品牌企业,一个公司可以做多少网站,网站托管服务使用于那种类型的网站截止到2020年五月#xff0c;JVM中仅仅只是关于垃圾回收和内存相关的参数就已经超过600个。如果算上其他方面的参数#xff0c;JVM相关的总参数能轻松超过1000个。参数太多了#xff0c;弄得人很懵逼。在这边文章中#xff0c;我们只选取了7个比较重要#xff0c;且有用的…截止到2020年五月JVM中仅仅只是关于垃圾回收和内存相关的参数就已经超过600个。如果算上其他方面的参数JVM相关的总参数能轻松超过1000个。参数太多了弄得人很懵逼。在这边文章中我们只选取了7个比较重要且有用的JVM参数来介绍。-Xmx 和 -XX:MaxMetaspaceSize-Xmx可能是最重要最常用的JVM参数了。-Xmx用来定义能分配给应用的最大堆空间大小。你可以像这样使用-Xmx2g堆空间大小直接决定着应用性能。但是随之而来的问题是对于一个应用应该设置多大的堆空间是合理的我应该为我的应用设置一个大的堆空间还是一个相对较小的答案是“看情况”这个问题另开一篇文章专门探讨。这里只提示一点将-Xmx和-Xms设置为相同能获得更好的性能。元空间是对JVM规范中方法区的实现用于存储JVM中的元数据信息比如类定义方法定义等。在默认情况下元空间使用的是本地内存空间所以理论上讲元空间地址是没有上限的他受限于机器的内存大小内存寻址空间大小等。可以通过以下参数来指定元空间的大小-XX:MaxMetaspaceSize512m //设置元空间最大空间-XX:MetaspaceSize //初始元空间大小对于-XX:MetaspaceSize来说达到该值就会触发垃圾收集进行类型卸载同时GC会对该值进行调整如果释放了大量的空间就适当降低该值如果释放了很少的空间那么在不超过MaxMetaspaceSize时适当提高该值。另除了上面两个指定大小的选项以外还有两个与 GC 相关的属性 -XX:MinMetaspaceFreeRatio在GC之后最小的Metaspace剩余空间容量的百分比减少为分配空间所导致的垃圾收集 -XX:MaxMetaspaceFreeRatio在GC之后最大的Metaspace剩余空间容量的百分比减少为释放空间所导致的垃圾收集GC回收器类型截止目前为止在OpenJDK中一共提供了7种类型的GC【这里注意区分一下GC回收器类型和GC回收算法】Serial GCParallel GCConcurrent Mark Sweep GCG1 GCShenandoah GCZ GCEpsilon GC如果没有特别的指定GC回收器JVM会使用默认的到Java8Parallel GC是默认回收器从Java9之后G1 GC是默认的GC回收器。使用何种GC回收器对于应用的性能表现起着至关重要的作用。 从测试数据来看Z GC有非常不错的表现。如果你的应用运行在JVM11以上我们建议优先考虑使用Z GC(-XX:UseZGC)。下表中列出了不同GC算法及其对应的开启参数Serial GC -XX:UseSerialGCParallel GC -XX:UseParallelGC Concurrent Market Sweep (CMS) GC -XX:UseConcMarkSweepGCG1 GC -XX:UseG1GCShenandoah GC -XX:UseShenandoahGCZ GC -XX:UseZGCEpsilon GC -XX:UseEpsilonGCEnable GC LoggingGC日志中包含了包括垃圾回收事件内存空间情况时间间隔等等。可以使用下面的JVM参数来开启GC日志。JDK8及其之前-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:{file-path}JDK9及之后-Xlog:gc*:file{file-path}一个详细例子-XX:PrintGCDetails -XX:PrintGCDateStamps -Xloggc:/opt/workspace/myAppgc.log-Xlog:gc*:file/opt/workspace/myAppgc.log一般情况下GC日志主要用来调整GC性能。然而GC日志中也包含了很多微观指标。这些指标可用于预测应用程序的可用性和性能。在这里我们只举一个例子“GC Throughput(GC吞吐量)”。GC吞吐量是应用程序处理应用事务所花费的时间与处理GC活动所花费的时间之比。比如应用的GC吞吐量是98%这意味着应用程序将98%的时间花在处理应用活动上剩下的2%花在GC活动上。接下来看一个健康的JVM的堆使用图你可以看到一个完美的锯齿图案。可以看到到当运行完整的GC(红色三角形)时内存利用率下降到了底部。再来看一个有问题的JVM堆使用图注意图案的右侧区域及时GC不断的运行内存利用率仍然没有明显下降。这就是一个出现了内存问题的典型迹象。当我们更仔细的分析这个图片我们可以看到在8点左右的时间完全GC开始重复出现知道8点45左右应用出现了OOM异常。8点之前GC的吞吐量在99%左右但是在8点之后GC的吞吐量掉到了60%因为大量重复GC的动作出现让应用已经没有太多时间处理应用的正常事务。一种主动的措施如果当发现GC吞吐量开始下降的时候我们可以从负载平衡群中取出该JVM。这样出现问题的JVM就不会处理任何新的流量可以最大限度地减少对客户请求的影响。可以使用GCeasy REST API实时监控GC的微观数据也可以使用gcviewer (https://github.com/chewiebug/GCViewer)离线分析GC日志文件。-XX:HeapDumpOnOutOfMemoryError, -XX:HeapDumpPathOOM异常严重影响应用的可用性/性能SLA等级。要诊断OOM异常或任何与内存相关的问题必须在应用程序开始遇到OOM之前的某一时刻或几分钟捕获heap dump(堆转储文件)。由于我们不知道OOM何时出来所以很难手动捕获它。一般通过传递以下JVM参数来自动捕获heap dump-XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath{HEAP-DUMP-FILE-PATH}在-XX:HeapDumpPath中我们设置一个堆转储文件地址。当这两个参数传递给JVM之后当抛出OOM的时候heap dump会被自动捕获并存储在指定文件路径上。一般可以使用jhat、EclipseMAT分析heap dump。-Xss每个应用在运行时都会产生大量线程每个线程拥有自己的栈空间。在每个线程栈中包含了以下内容当前正在执行的方法原始数据类型变量对象指针返回值每一项都占用内存。如果内存占用超过一定限制就会抛出StackOverflowError异常。可以使用-Xss参数来调整线程栈的大小。例如-Xss256k如果设置-Xss过大会造成内存的阻塞和浪费。例如假设我们设置-Xss大小为2MB但实际上只需要256KB就会造成非常大的内存浪费而不仅仅只是字面量上的1792KB。假设应用一共有500个线程当-Xss设置为2MB线程会总共占用1000MB内存。而如果设置-Xss为256KB实际总共只需要125MB内存空间总共节约了875MB内存。所以-Xss的设置会造成巨大的内存消耗差异。我们建议先将-Xss设置为一个较小的值比如256KB并使用该设置完成回归、性能和AB测试。如果在这个过程中遇到了StackOverflowError再逐步提高该值即可否则使用一个较小的值。-Dsun.net.client.defaultConnectTimeout 和 -Dsun.net.client.defaultReadTimeout在一个应用中常常会涉及到使用各种协议(SOAP, REST, HTTP, HTTPS, JDBC, RMI等)和第三方应用交互。有时候第三方应用会响应很慢或者无响应。在这种情况下如果没有一个合理的超时时间设置如果远端应用没法及时响应则会造成我们的应用线程/资源出现问题。远程应用程序无响应会影响我们程序的可用性。所以设置合理的超时时间是非常必要的。你可以通过设置这两个非常强大的网络参数在JVM层面上控制所有通过java.net.URLConnection建立的协议连接。sun.net.client.defaultConnectTimeout设置连接到主机的超时时间(毫秒)sun.net.client.defaultReadTimeout与资源建立连接时从输入流读取数据的超时时间(毫秒)比如-Dsun.net.client.defaultConnectTimeout2000-Dsun.net.client.defaultReadTimeout2000如果设置为-1则表示不超时。原文链接https://www.javacodegeeks.com/2020/03/7-jvm-arguments-of-highly-effective-applications.html
