blocks|key|3105077|text|如果您想真正了解VM内存中发生了什么，您应该使用像VisualVM这样的好工具。这是一个自由软件，这是一个很好的方式来了解正在发生的事情。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3105078|显式gc()调用没有什么真正的“错误”。但是，请记住，当您调用gc()时，您是在“建议”运行垃圾收集器。不能保证它将在您运行该命令的确切时间运行。|style|CODE|3105079|entityMap|0|LINK|mutability|MUTABLE|url|https://visualvm.github.io/^0|P|8|0|0|2|4|V|4|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@$A|U|B|V|F|G]|$A|W|B|X|F|G]]|9|@]|C|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

If you want to really look at what is going on in the VM memory you should use a good tool like <a href="https://visualvm.github.io/" rel="noreferrer">VisualVM</a>. This is Free Software and it's a great way to see what is going on.

Nothing is really "wrong" with explicit <code>gc()</code> calls. However, remember that when you call <code>gc()</code> you are "suggesting" that the garbage collector run. There is no guarantee that it will run at the exact time you run that command.

blocks|key|336190|text|我想说，顾问在理论上是正确的，而您在实践中是正确的。作为saying+goes|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|336191|336192|在理论上、理论上和实践上都是一样的。在实践中，它们并不是。|blockquote|336193|336194|336195|Java规范说System.gc建议调用垃圾收集。实际上，它只是产生一个线程，并立即在Sun+JVM上运行。|336196|尽管从理论上讲，您可能会搞乱垃圾收集的一些微调JVM实现，但除非您编写的泛型代码打算部署到任何JVM上，否则不必担心。如果对你有效，那就去做吧。|336197|entityMap|0|LINK|mutability|MUTABLE|url|http://www.quoteworld.org/quotes/1305^0|S|B|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@$A|W|B|X|1|Y]]|C|$]]|$1|D|3|-4|5|6|7|Z|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|10|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|11|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|12|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|15|8|@]|9|@]|C|$]]]|O|$P|$5|Q|R|S|C|$T|U]]]]

I would say that the consultant is right in the theory, and you are right in practice. As the <a href="http://www.quoteworld.org/quotes/1305" rel="noreferrer">saying goes</a>:

<blockquote>
 In theory, theory and practice are the same. In practice, they are not.
</blockquote>

The Java spec says that System.gc suggests to call garbage collection. In practice, it just spawns a thread and runs right away on the Sun JVM.

Although in theory you could be messing up some finely tuned JVM implementation of garbage collection, unless you are writing generic code intended to be deployed on any JVM out there, don't worry about it. If it works for you, do it.

blocks|key|3105205|text|看一下JVM：http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#DebuggingOptions|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3105206|3105207|+XX:-PrintGC在垃圾回收时打印消息。可管理的。|blockquote|3105208|3105209|-XX:-PrintGCDetails在垃圾回收时打印更多详细信息。可管理的。(在1.4.0中引入。)|3105210|-XX:-PrintGCTimeStamps在垃圾回收时打印时间戳。可管理(在1.4.0中引入。)|3105211|-XX:-PrintTenuringDistribution打印使用年限信息。|3105212|3105213|虽然对System.gc()的显式调用不会扰乱JVM，但它们可能不会产生预期的效果。要真正了解JVM中的内存发生了什么，请阅读Brian+Goetz写的任何内容和所有内容。|style|CODE|3105214|entityMap|0|LINK|mutability|MUTABLE|url|http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#DebuggingOptions^0|7|26|0|0|0|0|0|0|0|0|0|3|B|0^^$0|@$1|2|3|4|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|D|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|16|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|17|8|@]|9|@]|C|$]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|C|$]]|$1|K|3|L|5|6|7|19|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|C|$]]|$1|O|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1C|8|@$A|1D|B|1E|R|S]]|9|@]|C|$]]|$1|T|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]]|U|$V|$5|W|X|Y|C|$Z|10]]]]

Take a look at the JVM args: <a href="http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#DebuggingOptions" rel="nofollow noreferrer">http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp#DebuggingOptions</a>
<blockquote>
XX:-PrintGC Print messages at garbage collection. Manageable.
-XX:-PrintGCDetails Print more details at garbage collection.
Manageable. (Introduced in 1.4.0.)
-XX:-PrintGCTimeStamps Print timestamps at garbage collection.
Manageable (Introduced in 1.4.0.)
-XX:-PrintTenuringDistribution Print tenuring age information.
</blockquote>
While you're not going to upset the JVM with explicit calls to <code>System.gc()</code> they may not have the effect you are expecting. To really understand what's going on with the memory in a JVM with read anything and everything the Brian Goetz writes.

blocks|key|338669|text|如果你使用的是java1.5，你可以看看ManagementFactory.getMemoryMXBean()，它会给你所有类型的内存上的数字。堆和非堆，perm-gen。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|338670|在http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space上可以找到一个很好的例子|offset|length|338671|entityMap|0|LINK|mutability|MUTABLE|url|http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space^0|0|1|26|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

If you use java 1.5, you can look at ManagementFactory.getMemoryMXBean() which give you
numbers on all kinds of memory. heap and non-heap, perm-gen.

A good example can be found there
<a href="http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space" rel="nofollow noreferrer">http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space</a>

blocks|key|3318028|text|有一些工具可以让您监控VM的内存使用情况。VM+can+expose+memory+statistics+using+JMX。您还可以通过print+GC+statistics查看内存随时间的变化情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3318029|调用System.gc()可能会损害GC的性能，因为对象将过早地从新一代移到旧一代，弱引用将被过早清除。这可能会导致内存效率降低，GC时间更长，缓存命中率降低(对于使用弱ref的缓存)。我同意你的顾问的观点:+System.gc()很糟糕。我甚至可以使用命令行开关来使用disable+it。|3318030|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html|1|http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html|2|http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#1.1.Other%2520Considerations%7Coutline^0|L|15|0|1X|J|1|0|3R|A|2|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]|$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@$A|Z|B|10|1|11]]|C|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]]]

There are tools that let you monitor the VM's memory usage. The <a href="https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html" rel="noreferrer">VM can expose memory statistics using JMX</a>. You can also <a href="http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html" rel="noreferrer">print GC statistics</a> to see how the memory is performing over time. 

Invoking System.gc() can harm the GC's performance because objects will be prematurely moved from the new to old generations, and weak references will be cleared prematurely. This can result in decreased memory efficiency, longer GC times, and decreased cache hits (for caches that use weak refs). I agree with your consultant: System.gc() is bad. I'd go as far as to <a href="http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#1.1.Other%20Considerations|outline" rel="noreferrer">disable it</a> using the command line switch.

blocks|key|3318043|text|在生产系统上显式运行System.gc()是一个糟糕的想法。如果内存达到任何大小，整个系统都会在满GC运行时冻结。在一个多of大小的服务器上，这很容易被注意到，这取决于jvm是如何配置的，以及它有多大的净空空间，等等-我已经看到超过30秒的暂停。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3318044|另一个问题是，显式调用GC实际上并不是在监控JVM是如何运行GC的，实际上是在改变它--根据您对JVM的配置，它将在适当的时候进行垃圾收集，并且通常是递增的(当内存耗尽时，它并不只是运行一个完整的GC+)。您将打印出的内容与JVM本身所做的完全不同--首先，您可能会看到较少的自动/增量GC，因为您将手动清除内存。|3318045|正如Nick+Holt的帖子所指出的那样，打印GC活动的选项已经作为JVM标志存在。|3318046|你可以有一个线程，以合理的时间间隔免费打印出来，这将显示你实际的内存使用情况。|3318047|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Explicitly running System.gc() on a production system is a terrible idea. If the memory gets to any size at all, the entire system can freeze while a full GC is running. On a multi-gigabyte-sized server, this can easily be very noticeable, depending on how the jvm is configured, and how much headroom it has, etc etc - I've seen pauses of more than 30 seconds. 

Another issue is that by explicitly calling GC you're not actually monitoring how the JVM is running the GC, you're actually altering it - depending on how you've configured the JVM, it's going to garbage collect when appropriate, and usually incrementally (It doesn't just run a full GC when it runs out of memory). What you'll be printing out will be nothing like what the JVM will do on it's own - for one thing you'll probably see fewer automatic / incremental GC's as you'll be clearing the memory manually. 

As Nick Holt's post points out, options to print GC activity already exist as JVM flags.

You could have a thread that just prints out free and available at reasonable intervals, this will show you actual mem useage.

blocks|key|3105285|text|正如所建议的那样，尝试使用VisualVM来获得基本视图。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3105286|您还可以使用Eclipse+MAT进行更详细的内存分析。|3105287|只要你不依赖System.gc()，为了程序的正确性，做它是可以的。|3105288|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

As has been suggested, try VisualVM to get a basic view.

You can also use Eclipse MAT, to do a more detailed memory analysis.

It's ok to do a System.gc() as long as you dont depend on it, for the correctness of your program.

blocks|key|338736|text|如果您喜欢从命令行执行此操作的好方法，请使用jstat：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|338737|http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html|offset|length|338738|它以可配置的时间间隔提供原始信息，这对于日志记录和绘图目的非常有用。|338739|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1P|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@$D|Q|E|R|1|S]]|A|$]]|$1|F|3|G|5|6|7|T|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|C]]]]

If you like a nice way to do this from the command line use jstat:

<a href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html" rel="nofollow noreferrer">http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html</a>

It gives raw information at configurable intervals which is very useful for logging and graphing purposes.

blocks|key|3105407|text|system.gc的问题在于，它已经根据内存使用情况自动分配时间给垃圾收集器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3105408|但是，例如，如果您在内存非常有限的情况下工作，比如移动设备，System.gc允许您手动分配更多的时间用于垃圾收集，但代价是cpu时间(但是，正如您所说的，您并不担心gc的性能问题)。|3105409|最佳实践可能是仅在您可能正在执行大量释放(如刷新大型数组)的情况下使用它。|3105410|总而言之，既然您只关心内存使用情况，那么可以随意调用gc，或者，更好的是，看看它是否对您的内存有很大影响，然后再决定。|3105411|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

The problem with system.gc, is that the JVM already automatically allocates time to the garbage collector based on memory usage.

However, if you are, for instance, working in a very memory limited condition, like a mobile device, System.gc allows you to manually allocate more time towards this garbage collection, but at the cost of cpu time (but, as you said, you aren't that concerned about performance issues of gc).

Best practice would probably be to only use it where you might be doing large amounts of deallocation (like flushing a large array).

All considered, since you are simply concerned about memory usage, feel free to call gc, or, better yet, see if it makes much of a memory difference in your case, and then decide.

blocks|key|3318228|text|通过Visual+VM窥探tomcat内部正在发生的事情。http://www.skill-guru.com/blog/2010/10/05/increasing-permgen-size-in-your-server/|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3318229|📷|atomic|3318230|​|3318231|3318232|3318233|3318234|entityMap|0|LINK|mutability|MUTABLE|url|http://www.skill-guru.com/blog/2010/10/05/increasing-permgen-size-in-your-server/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/05a003eba13ed1b9ccb7bf59a2c6e075.png|imageAlt|2^0|T|29|0|0|0|1|1|0|0|0|0|1|2|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|F|7|14|8|@]|9|@$A|15|B|16|1|17]]|C|$]]|$1|G|3|H|5|6|7|18|8|@]|9|@]|C|$]]|$1|I|3|H|5|6|7|19|8|@]|9|@]|C|$]]|$1|J|3|E|5|F|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|K|3|H|5|6|7|1E|8|@]|9|@]|C|$]]|$1|L|3|-4|5|6|7|1F|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|U|P|V|C|$W|X|Y|-4]]|Z|$5|U|P|V|C|$W|X|Y|-4]]]]

Peek into what is happening inside tomcat through Visual VM.
<a href="http://www.skill-guru.com/blog/2010/10/05/increasing-permgen-size-in-your-server/" rel="noreferrer">http://www.skill-guru.com/blog/2010/10/05/increasing-permgen-size-in-your-server/</a>
<img src="https://i.stack.imgur.com/rlf5g.png" alt="alt text">

<img src="https://i.stack.imgur.com/rlf5g.png" alt="alt text">

blocks|key|337784|text|如果你使用JMX提供的GC运行的历史记录，你可以使用相同的之前/之后的数字，你只是不需要强制GC。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337785|您只需记住，这些GC运行(通常一次用于旧的，一次用于新一代)不是在常规间隔上运行的，因此您还需要提取绘制的开始时间(或者根据序列号进行绘制，对于大多数实际目的来说，这对于绘制就足够了)。|337786|例如，在装有ParNewGC的Oracle+HotSpot+VM上，有一个名为java.lang:type=GarbageCollector,name=PS+Scavenge的JMX+MBean，它有一个属性LastGCInfo，它返回最后一次YG清道夫运行的CompositeData。它是用duration，absolute+startTime和memoryUsageBefore和memoryUsageAfter记录的。|offset|length|style|CODE|337787|只需使用计时器读取该属性即可。无论何时出现新的startTime，您都知道它描述了一个新的GC事件，您提取内存信息并保持轮询以等待下一次更新。(不确定是否可以以某种方式使用AttributeChangeNotification。)|337788|提示:您可以在计时器中测量到最后一次GC运行的距离，如果对于绘图结果来说这个距离太长，您可以有条件地调用System.gc()。但我不会在OLTP实例中这样做。|337789|entityMap^0|0|0|13|1C|43|8|4L|9|4V|H|5D|G|0|2E|R|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@$F|S|G|T|H|I]|$F|U|G|V|H|I]|$F|W|G|X|H|I]|$F|Y|G|Z|H|I]|$F|10|G|11|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|12|8|@$F|13|G|14|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|15|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|O|$]]

If you use the JMX provided history of GC runs you can use the same before/after numbers, you just dont have to force a GC. 

You just need to keep in mind that those GC runs (typically one for old and one for new generation) are not on regular intervalls, so you need to extract the starttime as well for plotting (or you plot against a sequence number, for most practical purposes that would be enough for plotting). 

For example on Oracle HotSpot VM with ParNewGC, there is a JMX MBean called <code>java.lang:type=GarbageCollector,name=PS Scavenge</code>, it has a attribute LastGCInfo, it returns a CompositeData of the last YG scavenger run. It is recorded with <code>duration</code>, absolute <code>startTime</code> and <code>memoryUsageBefore</code> and <code>memoryUsageAfter</code>.

Just use a timer to read that attribute. Whenever a new startTime shows up you know that it describes a new GC event, you extract the memory information and keep polling for the next update. (Not sure if a <code>AttributeChangeNotification</code> somehow can be used.)

Tip: in your timer you might measure the distance to the last GC run, and if that is too long for the resulution of your plotting, you could invoke System.gc() conditionally. But I would not do that in a OLTP instance.

blocks|key|3318292|text|你可以看看stagemonitor。它是一个开源的java+(web)应用程序性能监视器。它捕获响应时间指标、JVM指标、请求细节(包括由请求分析器捕获的调用堆栈)等。开销非常低。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3318293|您还可以选择使用强大的timeseries数据库石墨来存储数据点的长期历史记录，您可以使用花哨的仪表板查看这些数据点。|3318294|示例：|3318295|📷|atomic|3318296|​|3318297|查看project+website以查看屏幕截图、功能描述和文档。|3318298|注:我是stagemonitor的开发者|3318299|entityMap|0|LINK|mutability|MUTABLE|url|http://www.stagemonitor.org/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/33d5a4e135ab9bd5e87cbd409ffa173a.png|imageAlt|2^0|5|C|0|0|0|0|0|1|1|0|0|2|F|2|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1A|8|@]|9|@]|C|$]]|$1|H|3|I|5|J|7|1B|8|@]|9|@$A|1C|B|1D|1|1E]]|C|$]]|$1|K|3|L|5|6|7|1F|8|@]|9|@]|C|$]]|$1|M|3|N|5|6|7|1G|8|@]|9|@$A|1H|B|1I|1|1J]]|C|$]]|$1|O|3|P|5|6|7|1K|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]]|R|$S|$5|T|U|V|C|$W|X]]|Y|$5|Z|U|10|C|$11|12|13|-4]]|14|$5|T|U|V|C|$W|X]]]]

You can take a look at <a href="http://www.stagemonitor.org/">stagemonitor</a>. It is a open source java (web) application performance monitor. It captures response time metrics, JVM metrics, request details (including a call stack captured by the request profiler) and more. The overhead is very low.

Optionally, you can use the great timeseries database graphite with it to store a long history of datapoints that you can look at with fancy dashboards.

Example:
<img src="https://i.stack.imgur.com/WFzDk.png" alt="JVM Memory Dashboard">

Take a look at the <a href="http://www.stagemonitor.org/">project website</a> to see screenshots, feature descriptions and documentation.

Note: I am the developer of stagemonitor

blocks|key|337811|text|关于System.gc()…我刚刚在Oracle的文档中读到了下面的句子here|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|337812|337813|显式垃圾收集的性能影响可以通过使用标志-XX:%2BDisableExplicitGC禁用它们来测量，这会导致VM忽略对System.gc()的调用。|blockquote|337814|337815|337816|如果您的VM供应商和版本支持该标志，则可以在使用和不使用该标志的情况下运行代码，并比较性能。|337817|另请注意，前面引用的句子前面有这个句子：|337818|337819|这可以在可能不需要的时候强制执行大收集(例如，当小收集就足够了)，因此通常应该避免这样做。|337820|337821|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html#sthref63^0|10|4|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]]|C|$]]|$1|D|3|-4|5|6|7|13|8|@]|9|@]|C|$]]|$1|E|3|F|5|G|7|14|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|15|8|@]|9|@]|C|$]]|$1|I|3|-4|5|6|7|16|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|17|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|18|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|19|8|@]|9|@]|C|$]]|$1|O|3|P|5|G|7|1A|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1B|8|@]|9|@]|C|$]]|$1|R|3|-4|5|6|7|1C|8|@]|9|@]|C|$]]]|S|$T|$5|U|V|W|C|$X|Y]]]]

About System.gc()… I just read in Oracle's documentation the following sentence <a href="https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/considerations.html#sthref63" rel="nofollow noreferrer">here</a>

<blockquote>
 The performance effect of explicit garbage collections can be measured by disabling them using the flag -XX:+DisableExplicitGC, which causes the VM to ignore calls to System.gc().
</blockquote>

If your VM vendor and version supports that flag you can run your code with and without it and compare Performance.

Also note the previous quoted sentence is preceded by this one:

<blockquote>
 This can force a major collection to be done when it may not be necessary (for example, when a minor collection would suffice), and so in general should be avoided. 
</blockquote>

blocks|key|338904|text|JavaMelody可能是满足您需求的解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|338905|这个工具是为Java应用程序开发的，它测量和构建有关应用程序在任何环境中的实际操作的报告。它是免费的，开源的，很容易集成到有历史记录的应用程序中，没有数据库，也没有分析，真的很轻量级。|338906|entityMap|0|LINK|mutability|MUTABLE|url|https://github.com/javamelody/javamelody^0|0|A|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

<a href="https://github.com/javamelody/javamelody" rel="nofollow noreferrer">JavaMelody</a> might be a solution for your need.
Developed for Java EE applications, this tool measure and build report about the real operation of your applications on any environments. It's free and open-source and easy to integrate into applications with some history, no database nor profiling, really lightweight.

We have a j2ee application running on Jboss and we want to monitor its memory usage. Currently we use the following code 

<pre><code> System.gc();
 Runtime rt = Runtime.getRuntime();
 long usedMB = (rt.totalMemory() - rt.freeMemory()) / 1024 / 1024;
 logger.information(this, "memory usage" + usedMB);
</code></pre>

This code works fine. That means it shows memory curve which corresponds to reality. When we create a big xml file from a DB a curve goes up, after the extraction is finished it goes down. 

<img src="https://i6.photobucket.com/albums/y231/oleg_pavliv/hc.jpg" alt="alt text">

A consultant told us that calling gc() explicitly is wrong, "let jvm decide when to run gc". Basically his arguments were the same as <a href="https://stackoverflow.com/questions/66540/system-gc-in-java">disscussed here</a>. 
But I still don't understand:

<ul>
<li>how can I have my memory usage curve?</li>
<li>what is wrong with the explicit gc()? I don't care about small performance issues which can happen with explicit gc() and which I would estimate in 1-3%. What I need is memory and thread monitor which helps me in analysis of our system on customer site.</li>
</ul>

How to monitor Java memory usage?

数据库

服务器

Eclipse

Java

OLTP

我们有一个运行在Jboss上的j2ee应用程序，我们想要监控它的内存使用情况。目前，我们使用以下代码    System.gc();    Runtime rt = Runtime.getRuntime();    long usedMB = (rt.totalMemory() - rt.freeMemory()) /...

问如何监控Java内存使用情况？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何监控Java内存使用情况？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何监控Java内存使用情况？
EN