VisualVM监控内存使用情况
在我的 tomcat 启动中，我将 -xms 、 -xmx 设置为 1GB。在 VisualVM 内部，当我监视内存
当我对内存进行采样时，它不会显示准确的内存使用情况，直到我按“快照”，然后利用内存的 Java 类才会显示正确的模式和实例计数。为什么这样？
另外，当我将 tomcat 内存设置为 1GB 时，内存会继续增加 zip-zat 并上升到大约 960mb。直到我按“perform gc”并且内存回到200mb..
您认为需要创建调度程序来强制每天午夜在 jvm 上执行 Perform.gc() 吗？
我的描述中的任何评论
in my tomcat startup, i set -xms , -xmx to 1GB. inside visualvm when i monitor memory
when i do sampling of memory, it doesnt show accurate memory usage, until, if i press 'snapshot', and then the java classes that utilizing memory showing correct patterns and instances count. why like this?
also, as i set tomcat memory to 1gb, memory keep on increasing ing zip-zat and go up aroudn 960mb. until i press "perform gc" and the memory back to 200mb..
do you think needed to create scheduler to force hit perform.gc() on jvm ,everday at midnight?
any comments from my description
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我相信您在这里看到的是并发垃圾收集器正在执行年轻代清理，但堆不断搅拌，因此它无法获取老一代收集的所有引用。当您点击“执行 GC”按钮时，您正在执行“停止世界”收集，该收集会阻止所有线程、冻结堆并允许发生更大的收集。我在这里主要关心的是 - 是否曾经发生过大型收集（x 小时后）？您是否在较小的堆中看到 OutOfMemory 错误？
1）您是否打开了自动刷新按钮？也可能是分析器在拍摄快照之前执行一次小型 GC（Eden 空间）。
2）这是完全正常的。垃圾收集需要时间和资源（处理器周期）。如果您将堆设置为很大的大小，它将等到它达到一定百分比，然后触发垃圾收集本身。我认为默认的可用空间与活动对象的比率在 40% 到 70% 之间，我知道 tomcat 在版本 5 中专门改变了垃圾收集的方式，tomcat v4 存在性能问题，因为它花费了大量时间运行垃圾收集器。您可能想在这里做一些研究，看看 tomcat 是否有自定义垃圾收集选项。
3) 不。几乎满的堆正是您所追求的。缩小堆可能是有意义的，这样完整的垃圾回收就不会花费这么长时间。这是大量垃圾收集（暂停）和长时间垃圾收集（长时间暂停）之间的权衡。每个应用程序都是不同的，因此我通常从默认值开始，然后根据需要进行调整。如果您感兴趣，有很多垃圾收集（和备用收集器）的选项。
Java 5
Java 6 常见问题解答, 白皮书
What I believe you see here is the concurrent Garbage Collector is doing young generation cleanups, but the heap is constantly churning so it can't get a hold of all the references for an old generation collection. When you hit the perform GC button you're doing a "stop-the-world" collection which blocks all the threads, freezing the heap, and allowing a much larger collection to occur. My main concerns here would be - does a large collection ever occur (after x hours)? Are you seeing OutOfMemory errors with a smaller heap?
1) Do you have the auto refresh button turned on? It may also be that profiler does a small GC (Eden space) before taking a snapshot.
2) This is perfectly normal. Garbage collection takes time and resources (processor cycles). If you've set your heap to a large size, it will wait until it reaches some percentage of that until triggering a garbage collection itself. I think the default free space to live object ratio is between 40% and 70% I know tomcat specifically changed the way it does garbage collection around version 5, tomcat v4 had performance issues because it spent a lot of time running the garbage collector. You may want to do some research here and see if tomcat has custom garbage collection options.
3) No. A nearly full heap is exactly what you're striving for. It may make sense to make the heap smaller so that a full garbage collection doesn't take such a long time. It's trade-off between lots of garbage collections (pauses) and lengthy garbage collections (long pauses). Each app is different, so I generally start with the defaults and tweak as needed. There are lots of options for garbage collection (and alternate collectors) if you're interested.
Java 5
Java 6 FAQ, Whitepaper