WCF InstanceContextMode.PerCall模式下文件锁未释放的原因探究

Great question—this gets to the heart of how .NET managed resources interact with Windows OS-level primitives, so let's unpack this clearly:

1. What InstanceContextMode.PerCall Actually Controls #

First, let's set the record straight: PerCall does destroy the WCF Service instance and its in-memory variables when the request finishes. But here's the catch: the service instance is just a managed object in your .NET process. It doesn't directly control OS-level resources like file locks.

2. Why the File Lock Persists After the Service Instance is Destroyed #

File locks in Windows are tied to OS file handles, not .NET objects like FileStream or your service class. Here's the chain:

• When you open a file in .NET (e.g., with new FileStream(...)), the runtime makes a call to Windows API functions like CreateFileW to get a kernel-level file handle.
• The FileStream object is just a managed wrapper around this handle. It holds a reference to the handle, but the lock itself is managed entirely by the Windows kernel.
• If you don't explicitly dispose of the FileStream (via using blocks, calling .Dispose(), or .Close()), the managed object will eventually be cleaned up by the Garbage Collector (GC). But the GC runs on its own schedule—it won't immediately clean up the object when the service instance is destroyed.
• Until the GC runs the finalizer for the FileStream (which tells Windows to release the handle), the OS keeps the file locked.

3. Why Recycling the App Pool Fixes It #

Recycling the app pool terminates the entire w3wp.exe process (the worker process running your WCF service). Windows has a hard rule: when a process exits, the OS automatically reclaims all kernel-level resources owned by that process—including open file handles. This bypasses any lingering managed objects or unexecuted finalizers, which is why the lock disappears immediately.

4. Why PerCall Doesn't Have the Same Effect as App Pool Recycling #

InstanceContextMode.PerCall only manages the lifecycle of your WCF service instances. It doesn't trigger a GC collection, nor does it force the finalization of all managed resources held by the instance. The service instance is marked for GC, but the actual cleanup (and handle release) happens later, whenever the GC decides to run.

A Quick Fix to Avoid This #

The simplest way to prevent this issue is to always wrap file operations in using blocks, which ensure the FileStream is disposed immediately when done:

using (var stream = new FileStream("example.txt", FileMode.Open))
{
    // Perform file operations here
}
// Stream is disposed here, handle is released, lock is lifted immediately

This way, you don't have to rely on the GC or service instance lifecycle to clean up OS resources.

内容的提问来源于stack exchange，提问作者kvirk