工具类网页 规格严格

http://rensanning.iteye.com/blog/1545708?page=2#comments

http://www.iteye.com/topic/1124225

http://www.linuxeden.com/plus/view.php?aid=67067

http://www.h3c.com.cn/Service/Document_Center/Routers/Catalog/SR_Router/SR8800/Configure/Operation_Manual/H3C_SR8800_OM%28Release3242_V3.08%29/02/201203/741221_30005_0.htm#_Toc259443787
 
http://www.h3c.com.cn/Service/Document_Center/Wlan/WX/H3C_WX3000/Configure/Operation_Manual/H3C_WX3000_OM-6PW103/200907/643517_30005_0.htm

From the source for OpenJDK I would say it is

const bool is_system_gc = gc_cause == GCCause::_java_lang_system_gc;

// This is useful for debugging but don't change the output the
// the customer sees.
const char* gc_cause_str = "Full GC";
if (is_system_gc && PrintGCDetails) {
  gc_cause_str = "Full GC (System)";
}

I created a custom version of the Runtime class to record the thread name and stack trace to a file whenever Runtime.getRuntime().gc() was called. (System.gc() calls this) I found it useful in tracking down and removing such callers.

One place this happens is in sun.misc.GC class. The RMI will ask this class to ensure a GC has been performing in the last N seconds. If there has been no GC it triggers a full GC.

This only shows as a problem if you reduce the number of minor GCs. Ironicly it can mean you get more full GCs. ;)

I don't use RMI (except perhaps JConsole) So I have it set to a week. (Think the default is an hour)

-Dsun.rmi.dgc.server.gcInterval=604800000
-Dsun.rmi.dgc.client.gcInterval=604800000
 
http://www.ibm.com/developerworks/java/jdk/tools/memoryanalyzer/

http://stackoverflow.com/questions/1518213/read-java-jvm-startup-parameters-eg-xmx
 

原文地址:https://www.cnblogs.com/diyunpeng/p/2534793.html