分析 API 中的垃圾回收
探查器可以接收垃圾回收通知。
如果用户指定了 COR_PRF_MONITOR_GC 标志，将会在探查器中引发除 ICorProfilerCallback::ObjectAllocated 事件外的所有垃圾回收事件。 出于性能方面的原因，ObjectAllocated 事件由 COR_PRF_MONITOR_OBJECT_ALLOCATED 标志明确控制。 请注意，如果启用了 COR_PRF_MONITOR_GC 标志，则会禁用并发垃圾回收。
在 .NET Framework 1.0 和 1.1 版中，如果挂起原因是 COR_PRF_SUSPEND_FOR_GC，代码探查器将通过监视 ICorProfilerCallback::RuntimeSuspendFinished 和 ICorProfilerCallback::RuntimeResumeStarted 回调来确定垃圾回收正在进行。 在关闭期间，公共语言运行时 (CLR) 也会挂起，并且，可能在不通知代码探查器的情况下进行一次或多次垃圾回收，原因是运行时已处于挂起状态。 在这些情形下，检测垃圾回收的完成并非无足轻重。 代码探查器必须检测 ICorProfilerCallback::ObjectReferences 或 ICorProfilerCallback::RootReferences 回调后发生的第一次 ObjectAllocated 回调。
在 .NET Framework 2.0 版和更高版本中，代码探查器可以使用 ICorProfilerCallback2::GarbageCollectionStarted 和 ICorProfilerCallback2::GarbageCollectionFinished 回调来确定垃圾回收正在进行，并确定已涵盖了哪些代。 （有关垃圾回收的代的更多信息，请参见 COR_PRF_GC_GENERATION 枚举。）这些回调没有上一节中提到的关闭问题。
.gif "注意") 注意 |
|---|
如果应用程序在实现 Intel Itanium 体系结构的 64 位系统（以前称为 IA-64）上运行 WOW64 x86 仿真程序，则在这些应用程序中不支持并发垃圾回收。有关在 64 位 Windows 系统上使用 WOW64 的更多信息，请参见 Running 32-bit Applications（运行 32 位应用程序）。 |
阻止垃圾回收
当公共语言运行时调用 ICorProfilerCallback 接口中的某些方法时，运行时将无法执行垃圾回收，直至探查器从该调用返回控制为止。 这是因为分析服务无法始终使堆栈处于可以安全进行垃圾回收的状态。 因此，在回调过程中将禁用垃圾回收。 在这些情况下，探查器应尽快返回控制。 下列回调将会出现此情形：
ICorProfilerCallback::ExceptionOSHandlerEnter、ICorProfilerCallback::ExceptionOSHandlerLeave
ICorProfilerCallback::ExceptionUnwindFunctionEnter、ICorProfilerCallback::ExceptionUnwindFunctionLeave
ICorProfilerCallback::ExceptionUnwindFinallyEnter、ICorProfilerCallback::ExceptionUnwindFinallyLeave
ICorProfilerCallback::ExceptionCatcherEnter、ICorProfilerCallback::ExceptionCatcherLeave
ICorProfilerCallback::ExceptionCLRCatcherFound、ICorProfilerCallback::ExceptionCLRCatcherExecute
ICorProfilerCallback::COMClassicVTableCreated、ICorProfilerCallback::COMClassicVTableDestroyed
此外，下列回调允许探查器通过使用 fIsSafeToBlock 参数逐个调用阻止垃圾回收：
请注意，如果探查器进行了阻止，它将延迟垃圾回收。 只要探查器不调用触发垃圾回收或在托管堆中分配空间的 CLR 函数，这种延迟就无关紧要。