我在java 7上有一个java servlet应用程序，它在系统资源消耗方面通常非常健康。通常，服务器上的CPU使用率低于50%。然而，在启动后的几分钟内，它的表现大不相同，以至于如果CPU试图在这段时间内提供大量流量，它可能会在几分钟内保持100%。其结果是响应时间慢、网络超时，有时甚至会出现长时间的垃圾收集暂停。
为了诊断这个问题，我在服务器启动时进行了一系列线程转储，同时运行top-H。通过将每个java线程与pid匹配，我可以一致地看到C2 CompilerThread使用了迄今为止最多的CPU。我已经研究过这个线程的作用，我知道它是一个基于运行时统计信息优化代码的Java编译器。但从我所做的所有阅读来看，我无法说出改善情况的最佳方法。我能收集到的唯一选项是：
- 从C2切换到TieredCompiler（但这会在启动后的最初几分钟内带来更好的性能吗？）
- 打开-XX:+PrintCompilation查看正在优化的内容（但我该如何处理这些信息？我可以在服务器以某种方式接受流量之前强制进行优化吗？）
最好的方法是什么？有没有其他选择可以在启动后尝试减少CPU使用？
有几种付费JVM技术可以使用提前编译来缓解您的问题。
然而，如果您想坚持使用标准JVM，人们使用的一个技巧是在启动后发送一些伪请求，以便在实际操作开始之前预热JVM。这样，您就可以在为客户服务之前决定何时支付JVM预热成本。
您也可以通过热点的-Xcomp命令行选项强制JVM编译所有代码，但我们不建议使用，因为编译少量使用的代码会减慢应用程序的启动速度。
我在第一次调用instrumentation.retransformClasses(clazz);后遇到了同样的问题。instrumentation是关于java代理的java.lang.instructure。
以下是从JDK源代码中retransformClasses所做的操作。
/**
* Retransform the supplied set of classes.
*
* <P>
* This function facilitates the instrumentation
* of already loaded classes.
* When classes are initially loaded or when they are
* {@linkplain #redefineClasses redefined},
* the initial class file bytes can be transformed with the
* {@link java.lang.instrument.ClassFileTransformer ClassFileTransformer}.
* This function reruns the transformation process
* (whether or not a transformation has previously occurred).
* This retransformation follows these steps:
* <ul>
* <li>starting from the initial class file bytes
* </li>
* <li>for each transformer that was added with <code>canRetransform</code>
* false, the bytes returned by
* {@link java.lang.instrument.ClassFileTransformer#transform transform}
* during the last class load or redefine are
* reused as the output of the transformation; note that this is
* equivalent to reapplying the previous transformation, unaltered;
* except that
* {@link java.lang.instrument.ClassFileTransformer#transform transform}
* is not called
* </li>
* <li>for each transformer that was added with <code>canRetransform</code>
* true, the
* {@link java.lang.instrument.ClassFileTransformer#transform transform}
* method is called in these transformers
* </li>
* <li>the transformed class file bytes are installed as the new
* definition of the class
* </li>
* </ul>
* <P>
*
* The order of transformation is described in the
* {@link java.lang.instrument.ClassFileTransformer#transform transform} method.
* This same order is used in the automatic reapplication of retransformation
* incapable transforms.
* <P>
*
* The initial class file bytes represent the bytes passed to
* {@link java.lang.ClassLoader#defineClass ClassLoader.defineClass} or
* {@link #redefineClasses redefineClasses}
* (before any transformations
* were applied), however they might not exactly match them.
* The constant pool might not have the same layout or contents.
* The constant pool may have more or fewer entries.
* Constant pool entries may be in a different order; however,
* constant pool indices in the bytecodes of methods will correspond.
* Some attributes may not be present.
* Where order is not meaningful, for example the order of methods,
* order might not be preserved.
*
* <P>
* This method operates on
* a set in order to allow interdependent changes to more than one class at the same time
* (a retransformation of class A can require a retransformation of class B).
*
* <P>
* If a retransformed method has active stack frames, those active frames continue to
* run the bytecodes of the original method.
* The retransformed method will be used on new invokes.
*
* <P>
* This method does not cause any initialization except that which would occur
* under the customary JVM semantics. In other words, redefining a class
* does not cause its initializers to be run. The values of static variables
* will remain as they were prior to the call.
*
* <P>
* Instances of the retransformed class are not affected.
*
* <P>
* The retransformation may change method bodies, the constant pool and attributes.
* The retransformation must not add, remove or rename fields or methods, change the
* signatures of methods, or change inheritance. These restrictions maybe be
* lifted in future versions. The class file bytes are not checked, verified and installed
* until after the transformations have been applied, if the resultant bytes are in
* error this method will throw an exception.
*
* <P>
* If this method throws an exception, no classes have been retransformed.
* <P>
* This method is intended for use in instrumentation, as described in the
* {@linkplain Instrumentation class specification}.
*
* @param classes array of classes to retransform;
* a zero-length array is allowed, in this case, this method does nothing
* @throws java.lang.instrument.UnmodifiableClassException if a specified class cannot be modified
* ({@link #isModifiableClass} would return <code>false</code>)
* @throws java.lang.UnsupportedOperationException if the current configuration of the JVM does not allow
* retransformation ({@link #isRetransformClassesSupported} is false) or the retransformation attempted
* to make unsupported changes
* @throws java.lang.ClassFormatError if the data did not contain a valid class
* @throws java.lang.NoClassDefFoundError if the name in the class file is not equal to the name of the class
* @throws java.lang.UnsupportedClassVersionError if the class file version numbers are not supported
* @throws java.lang.ClassCircularityError if the new classes contain a circularity
* @throws java.lang.LinkageError if a linkage error occurs
* @throws java.lang.NullPointerException if the supplied classes array or any of its components
* is <code>null</code>.
*
* @see #isRetransformClassesSupported
* @see #addTransformer
* @see java.lang.instrument.ClassFileTransformer
* @since 1.6
*/
void
retransformClasses(Class<?>... classes) throws UnmodifiableClassException;