正如标题已经让你想知道的那样，这不应该被视为独家或吗？按照我理解 PerCall 的方式，每个新请求都应该创建一个新的 Service 对象，以及一组新的变量等等。那么文件上的锁怎么可能仍然存在呢？
想象一下，在 Request #1 期间文件没有正确关闭，不应该在 Request #1 结束时处理巨大的 Service 对象来处理对象吗？或者文件上的锁定是否可能不在服务对象手中，而是在内部 Windows api 机制的深处，在某种程度上，随着请求 #1 的结束，文件锁定仍然存在（不正确关闭发生），锁还在吗？回收了应用池后，锁已经没有了，但是InstanceContextMode.PerCall的设置不应该有同样的效果吗？
我将不胜感激对此的任何技术解释，嗯，我必须给它贴上标签的现象。我们不能打电话给 Andrew S. Tanenbaum，每次我们都不能处理这种问题，你不同意吗？但我想了解这类问题的内在循环。