不同任务能否在同一线程同时并发？ThreadStatic单例可靠性问询

Great question—this is a super common gotcha when moving from thread-based state management to modern task-based programming! Let's break this down clearly:

First, let's answer your core question directly, then cover why [ThreadStatic] might not be the right fit, and what to use instead.

1. Can a single thread run multiple tasks at the same time? #

Short answer: No, a thread can only execute one task at a time—but there are two critical nuances that make [ThreadStatic] risky for tasks:

• Thread re-use in the thread pool: When a task finishes, the thread it was running on gets returned to the thread pool and can be assigned to a new task later. The [ThreadStatic] instance stays attached to that thread, so the new task will inherit the old task's singleton instance. This isn't "simultaneous" execution, but it still leads to unintended sharing of state between tasks.
• Async/await thread hopping: When you await an incomplete operation, the current thread is released back to the pool. When the operation completes, the rest of your task might resume on a completely different thread. [ThreadStatic] doesn't follow this context switch—you'll lose your singleton instance when the thread changes, and if the new thread was used by another task before, you might pick up their leftover state.

2. Why [ThreadStatic] fails for task-scoped singletons #

[ThreadStatic] is tied to a thread, not a task's execution flow. Tasks are designed to be decoupled from specific threads (especially with async code), so binding your singleton to a thread means you're not actually getting a singleton per task—you're getting one per thread, which can be shared across multiple tasks over time.

3. The right tool: AsyncLocal<T> #

If you need a singleton that's exclusive to each task (including the entire lifecycle of an async task, even across thread hops), use AsyncLocal<T>. It's designed to track state across the asynchronous execution context, which follows your task through await calls and ensures each task (or task chain) gets its own isolated instance.

Here's a quick implementation example:

public static class TaskScopedSingleton
{
    // AsyncLocal holds the instance tied to the current task's context
    private static readonly AsyncLocal<MyService> _instance = new AsyncLocal<MyService>();

    public static MyService Instance
    {
        get
        {
            if (_instance.Value == null)
            {
                // Initialize a new instance only if none exists for this task
                _instance.Value = new MyService();
            }
            return _instance.Value;
        }
    }
}

This will give you a unique MyService instance for each independent task flow, even if the task moves between threads. Different tasks will never share the same instance.

4. Quick edge cases to keep in mind #

• If you're working with a sync context (like UI threads in WinForms/WPF), AsyncLocal still works perfectly—it distinguishes between different task flows even when they run on the same thread.
• If you create manual threads (not using the thread pool), AsyncLocal also works, since each thread starts with a fresh execution context.
• Avoid storing large or disposable objects in AsyncLocal unless you're careful to clean them up—they'll stick around as long as the execution context is alive.

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