问题描述

我有一个程序可以打开一个 Excel COM 对象，执行一些操作，然后关闭它.然后我想在它关闭后移动那个文件.如果我在没有断点的情况下运行程序，这可以正常工作.但是，如果我在调试模式之前进入某些东西，我会尝试移动文件，我得到一个 IOException:该进程无法访问该文件，因为它正被另一个进程使用."

I have a program that opens an Excel COM object, does some stuff, and closes it. Then I want to move that file after it's closed. This works fine if I run the program without break points. But, if I step into something in debug mode before I attempt to move the file I get an IOException: "The process cannot access the file because it is being used by another process."

那么交易是什么?当一个程序被允许全速运行而不是当我单步执行它时，垃圾收集的性能是否更好?单步执行我的代码不仅仅是非常缓慢地运行它吗?调试模式还有其他后果吗?仅仅因为我在调试而不运行exe而遇到的其他错误?

So what's the deal? Is garbage collection performing better while a program is allowed to run at full speed as opposed to while I am stepping through it? Is stepping through my code doing more than just very slowly running it? Are there other consequences to the debug mode? Other errors that are encountered simply because I am in debug and not running an exe?

推荐答案

不在调试器中运行时，垃圾收集的优化方式不同，是的.特别是，CLR 可以检测到变量不会用于方法的其余部分，并将其不再视为 GC 根.在调试器中，作用域中的变量在整个方法中充当 GC 根，因此您仍然可以使用调试器检查值.

Garbage collection is optimized differently when running not in the debugger, yes. In particular, the CLR can detect that a variable won't be used for the rest of a method, and treat it as not a GC root any more. In the debugger, variables in scope act as GC roots throughout the method so that you can still examine the values with the debugger.

但是，这应该很少成为问题 - 只有在终结器确实执行了一些清理操作并且您明确及时地整理事情时(例如，使用using 语句)你通常不会注意到差异.

However, that should rarely be a problem - it should only affect things if a finalizer actually performs some clean-up, and if you're explicitly tidying things up in a timely way (e.g. with using statements) you usually wouldn't notice the difference.

这篇关于垃圾收集是否在调试期间运行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！