IoC库中Per Web Request生命周期原理及请求识别方法咨询

Great question—this is a core piece of how request-scoped dependencies work, and it’s critical if you’re building your own DI container. Let’s break this down step by step.

How IoC Containers Detect a New Web Request #

At the heart of per-request scoping is hooking into the web framework’s request lifecycle. Here’s how it typically works:

• Web frameworks (like ASP.NET Core, Java Servlet, Express.js) fire events at the start and end of every request. IoC containers register handlers for these events to trigger scope creation and cleanup.
• When a new request comes in, the container spins up a dedicated request scope—an isolated sub-container that holds all instances tied to that specific request.
• This scope is tied directly to the framework’s built-in request context (e.g., HttpContext in .NET, ServletRequest in Java, the req object in Node.js). This context acts as the "anchor" that lets the container recognize when it’s dealing with the same request across different parts of your code.
• For example, in ASP.NET Core, the framework automatically creates an IServiceScope for each request and attaches it to HttpContext.RequestServices. Any dependency resolved through this scope is treated as request-scoped.

Do Requests Have Unique Identifiers? #

Absolutely—every web request gets a unique identifier, and this is often leveraged by IoC containers (and logging systems) to track request-scoped instances. Here’s what you need to know:

• Most web frameworks generate a built-in request ID out of the box:
  • .NET: HttpContext.TraceIdentifier
  • Java Servlets: ServletRequest.getRequestId() (or via framework-specific headers like Spring Boot’s X-Request-ID)
  • Node.js/Express: You can generate one using middleware (e.g., the uuid package) and attach it directly to the req object
• IoC containers may also generate their own unique ID for the request scope itself—separate from the framework’s request ID. This internal ID is used to map instances to the correct scope behind the scenes.
• These IDs are gold for debugging: you can log the request ID alongside dependency resolution events to trace exactly which instances belong to which request.

Implementing Per-Request Scoping in Your Own DI System #

If you’re building your own DI container, here’s a simplified, practical approach to handle per-request scoping:

1. Hook into the web framework’s lifecycle: Register callbacks for "request started" and "request finished" events to trigger scope setup and teardown.
2. Use async-safe context storage: Skip ThreadLocal (it breaks with async/await workflows) and opt for tools like .NET’s AsyncLocal<T>, Java’s InheritableThreadLocal (with caution for async), or attach the scope directly to the framework’s request object.
3. Create a scope on request startup: When a new request begins, instantiate a new scope (think of it as a dictionary or hash map to store instances for this request) and store it in your context storage.
4. Resolve dependencies from the active scope: When your container is asked for a request-scoped instance, check if an active request scope exists. If yes, return the existing instance from the scope; if not, create a new one and store it.
5. Clean up on request end: When the request finishes, dispose of all disposable instances in the scope and clear the context storage to avoid memory leaks.

Pro tip: Be extra careful with async operations—ensure your context storage persists across async boundaries. Tools like AsyncLocal<T> are designed specifically for this, and most modern web frameworks handle this automatically for their native request contexts.

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