为了实现这些功能，我必须对已有的代码进行稍微的修改。首先，为了确保在运行时@Status注解是可以看到的，我就必须再次更新@Retention，把它设置为@Retention(RetentionPolicy.RUNTIME)。请记住，@Retention控制着JVM什么时候抛弃注解信息。这样的设置意味着注解不仅可以被编译器插入字节码中，还能够使用新的Method.getAnnotation(Class)方法通过反射来进行访问。
现在我需要安排接收代码中没有明确处理的任何异常的通知了。在Java 1.4中，处理任何特定线程上未处理异常的最好方法是使用ThreadGroup子类并给该类型的ThreadGroup添加自己的新线程。但是Java 1.5提供了额外的功能。我可以定义UncaughtExceptionHandler接口的一个实例，并为任何特定的线程（或所有线程）注册它。
请注意，在例子中为特定异常注册可能更好，但是在Java 1.5.0beta1（#4986764）中有一个bug，它使这样操作无法进行。但是为所有线程设置一个处理程序是可以工作的，因此我就这样操作了。
现在我们拥有了一种截取未处理异常的方法了，并且这些异常必须被报告给用户。在GUI应用程序中，典型情况下这样的操作是通过弹出一个包含整个堆栈跟踪信息或简单消息的模式对话框来实现的。在例子中，我希望在产生异常的时候显示一个消息，但是我希望提供堆栈的@Status描述而不是类和方法的名称。为了实现这个目的，我简单地在Thread的StackTraceElement数组中查询，找到与每个框架相关的java.lang.reflect.Method对象，并查询它的堆栈注解列表。不幸的是，它只提供了方法的名称，没有提供方法的特征量（signature），因此这种技术不支持名称相同的（但@Status注解不同的）重载方法。
实现这种方法的示例代码可以在peekinginside-pt2.tar.gz文件的/code/04_exceptions目录中找到。
取样（Sampling）
我现在有办法把StackTraceElement数组转换为@Status注解堆栈。这种操作比表明看到的更加有用。Java 1.5中的另一个新特性--线程反省（introspection）--使我们能够从当前正在运行的线程中得到准确的StackTraceElement数组。有了这两部分信息之后，我们就可以构造JstatusBar的另一种实现。StatusManager将不会在发生方法调用的时候接收通知，而是简单地启动一个附加的线程，让它负责在正常的间隔期间抓取堆栈跟踪信息和每个步骤的状态。只要这个间隔期间足够短，用户就不会感觉到更新的延迟。
下面使"sampler"线程背后的代码，它跟踪另一个线程的经过：
class StatusSampler implements Runnable
{
private Thread watchThread;
public StatusSampler (Thread watchThread)
{
this.watchThread = watchThread;
}
public void run ()
{
while (watchThread.isAlive()) {
// 从线程中得到堆栈跟踪信息
StackTraceElement[] stackTrace =watchThread.getStackTrace();
// 从堆栈跟踪信息中提取状态消息
List＜Status＞ statusList =StatusFinder.getStatus(stackTrace);
Collections.reverse(statusList);
// 用状态消息建立某种状态
StatusState state = new StatusState();
for (Status s : statusList) {
String message = s.value();
state.push(message);
}
// 更新当前的状态
StatusManager.setState(watchThread,state);
//休眠到下一个周期
try {
Thread .sleep(SAMPLING_DELAY);
} catch (InterruptedException ex) {}
}
//状态复位
StatusManager.setState(watchThread,new StatusState());
}
}
与增加方法调用、手动或通过重构相比，取样对程序的侵害性（invasive）更小。我根本不需要改变建立过程或命令行参数，或修改启动过程。它也允许我通过调整SAMPLING_DELAY来控制占用的开销。不幸的是，当方法调用开始或结束的时候，这种方法没有明确的回调。除了状态更新的延迟之外，没有原因要求这段代码在那个时候接收回调。但是，未来我能够增加一些额外的代码来跟踪每个方法的准确的运行时。通过检查StackTraceElement是可以精确地实现这样的操作的。
通过线程取样实现JStatusBar的代码可以在peekinginside-pt2.tar.gz文件的/code/05_sampling目录中找到。
在执行过程中重构字节码
通过把取样的方法与重构组合在一起，我能够形成一种最终的实现，它提供了各种方法的最佳特性。默认情况下可以使用取样，但是应用程序的花费时间最多的方法可以被个别地进行重构。这种实现根本不会安装ClassTransformer，但是作为代替，它会一次一个地重构方法以响应取样过程中收集到的数据。
为了实现这种功能，我将建立一个新类InstrumentationManager，它可以用于重构和不重构独立的方法。它可以使用新的Instrumentation.redefineClasses方法来修改空闲的类，同时代码则可以不间断执行。前面部分中增加的StatusSampler线程现在有了额外的职责，它把任何自己"发现"的@Status方法添加到集合中。它将周期性地找出最坏的冒犯者并把它们提供给InstrumentationManager以供重构。这允许应用程序更加精确地跟踪每个方法的启动和终止时刻。
前面提到的取样方法的一个问题是它不能区分长时间运行的方法与在循环中多次调用的方法。由于重构会给每次方法调用增加一定的开销，我们有必要忽略频繁调用的方法。幸运的是，我们可以使用重构解决这个问题。除了简单地更新StatusManager之外，我们将维护每个重构的方法被调用的次数。如果这个数值超过了某个极限（意味着维护这个方法的信息的开销太大了），取样线程将会永远地取消对该方法的重构。
理想情况下，我将把每个方法的调用数量存储在重构过程中添加到类的新字段中。不幸的是，Java 1.5中增加的类转换机制不允许这样操作；它不能增加或删除任何字段。作为代替，我将把这些信息存储在新的CallCounter类的Method对象的静态映射中。
这种混合的方法可以在示例代码的/code/06_dynamic目录中找到。
概括
图4提供了一个矩形，它显示了我给出的例子相关的特性和代价。
图4.重构方法的分析