我需要在Java中检查服务器的CPU和内存使用情况，有人知道如何做到这一点吗？

解决方案

回答

如果我们使用的是Tomcat，请签出Psi Probe，使用它可以监视内部和外部内存消耗以及许多其他区域。

回答

Java的Runtime对象可以报告JVM的内存使用情况。对于CPU消耗，我们必须使用外部实用程序，例如Unix的top或者Windows Process Manager。

回答

对于内存使用，以下方法将起作用，

long total = Runtime.getRuntime().totalMemory();
long used  = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();

对于CPU使用率，我们需要使用外部应用程序进行测量。

回答

JConsole是监视运行中的Java应用程序的简便方法，或者我们可以使用Profiler来获取有关应用程序的更多详细信息。我喜欢为此使用NetBeans Profiler。

回答

如果我们使用此处很多答案中都已发布的运行时/ totalMemory解决方案(我已经做了很多)，如果我们想要相当准确/一致的结果，请确保首先强制执行两个垃圾回收。

为了提高效率，Java通常允许垃圾在强制使用GC之前先填满所有内存，即使这样，它通常也不是完整的GC，因此，runtime.freeMemory()的结果始终在"实际"可用内存量和0之间。 。

第一个GC不能得到所有，它可以得到大部分。

上升是，如果我们仅执行freeMemory()调用，我们将得到一个绝对没有用的数字，并且数值相差很大，但是如果首先执行2 gc，则它是一个非常可靠的量规。这也使例行MUCH变慢(可能是几秒钟)。

回答

如果我们专门寻找JVM内存：

Runtime runtime = Runtime.getRuntime();

NumberFormat format = NumberFormat.getInstance();

StringBuilder sb = new StringBuilder();
long maxMemory = runtime.maxMemory();
long allocatedMemory = runtime.totalMemory();
long freeMemory = runtime.freeMemory();

sb.append("free memory: " + format.format(freeMemory / 1024) + "<br/>");
sb.append("allocated memory: " + format.format(allocatedMemory / 1024) + "<br/>");
sb.append("max memory: " + format.format(maxMemory / 1024) + "<br/>");
sb.append("total free memory: " + format.format((freeMemory + (maxMemory - allocatedMemory)) / 1024) + "<br/>");

但是，这些仅应作为估计值。

回答

从Java 1.5开始，JDK附带了一个新工具：JConsole wich可以向我们显示任何1.5或者更高版本JVM的CPU和内存使用情况。它可以绘制这些参数的图表，导出为CSV，显示加载的类数，实例数，死锁，线程等。

回答

YourKit Java分析器是一种出色的商业解决方案。我们可以在文档中找到有关CPU性能分析和内存性能分析的更多信息。

回答

JMX，提供的MXBean(ThreadMXBean等)将为我们提供内存和CPU使用率。

OperatingSystemMXBean operatingSystemMXBean = (OperatingSystemMXBean) ManagementFactory.getOperatingSystemMXBean();
operatingSystemMXBean.getSystemCpuLoad();

回答

如果我们使用的是Sun JVM，并且对应用程序的内部内存使用情况(应用程序使用的已分配内存中的多少)感兴趣，那么我更喜欢打开JVM的内置垃圾收集日志记录。我们只需在启动命令中添加-verbose：gc即可。

从Sun文档中：

The command line argument -verbose:gc prints information at every
  collection. Note that the format of the -verbose:gc output is subject
  to change between releases of the J2SE platform. For example, here is
  output from a large server application:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

  
  Here we see two minor collections and one major one. The numbers
  before and after the arrow

325407K->83000K (in the first line)

  
  indicate the combined size of live objects before and after garbage
  collection, respectively. After minor collections the count includes
  objects that aren't necessarily alive but can't be reclaimed, either
  because they are directly alive, or because they are within or
  referenced from the tenured generation. The number in parenthesis

(776768K) (in the first line)

  
  is the total available space, not counting the space in the permanent
  generation, which is the total heap minus one of the survivor spaces.
  The minor collection took about a quarter of a second.

0.2300771 secs (in the first line)

有关更多信息，请参见：http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html