java gc 释放应用程序
使用 jmx 并监视 Web 应用程序，我注意到当 GC (G1) 运行时，所有线程都被冻结，并且应用程序没有响应。我这样配置tomcat jvm：
-Xms2048m
-Xmx2048m
-XX:NewSize=512m
-XX:MaxNewSize=512m
-XX:PermSize=512m
-XX:MaxPermSize=512m
-XX:+DisableExplicitGC
-Xss2m
-XX:+CMSClassUnloadingEnabled
-XX:+UseG1GC
-Djava.net.preferIPv4Stack=true
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8338
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dhazelcast.logging.type=slf4j
当使用的堆内存达到最大限制（2GB）并且GC深度处理内存时，应用程序不会响应。 gc 工作后，已用堆减少到 300Mb。是否可以为 GC 设置不同的工作方式？这对我的应用程序来说是一个大问题，因为我使用 hazelcast 和 jgroups，每次 gc 工作时，都会导致集群分区。
我在此 Web 应用程序中使用的一些特殊库： 1) 榛子 1.9.4 2）阿卡0.10 3) 球衣1.2
Using jmx and monitoring a web application, I notice when th GC (G1) is runnig , all threads are freezed, and the application does not responde. I configured the tomcat jvm in like this:
-Xms2048m
-Xmx2048m
-XX:NewSize=512m
-XX:MaxNewSize=512m
-XX:PermSize=512m
-XX:MaxPermSize=512m
-XX:+DisableExplicitGC
-Xss2m
-XX:+CMSClassUnloadingEnabled
-XX:+UseG1GC
-Djava.net.preferIPv4Stack=true
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8338
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=true
-Dhazelcast.logging.type=slf4j
The application does not respond when the used heap memory reach the max limit (2GB) and the GC deeply work on memory. After the gc work the used heap goes down to 300Mb. Is it possibile to setup a different way to work for the GC? This is a big problem for my application because I use hazelcast and jgroups and every time the gc works, it cause a paartition of the cluster.
Some special libraries that I use in this web application:
1) hazelcast 1.9.4
2) akka 0.10
3) jersey 1.2
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题可能很简单，因为您需要
-XX:UnlockExperimentalVMOptions，因为（据我所知）G1GC 仍被认为是实验性的。如果这不起作用，您还可以使用各种其他实验性的、特定于 HotSpot 的 JVM 参数：
-XX:+UseParallelGC-XX:+UseConcMarkSweepGC参见http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html。
The problem may be as simple as the fact that you need
-XX:UnlockExperimentalVMOptions, since (AFAIK) G1GC is still considered experimental.There are a variety of other experimental, HotSpot-specific JVM args you can play around with if that doesn't do the trick:
-XX:+UseParallelGC-XX:+UseConcMarkSweepGCSee http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html.