Yes, each thread has its own stack. That's a hard necessity, the stack keeps track of where a method returns after it finishes, it stores the return address. Since each thread executes its own code, they need their own stack. Local variables and method arguments are stored there too, making them (usually) thread-safe.
The number of heaps is a more involved detail. You are counting 1 for the garbage collected heap. That's not entirely correct from an implementation point of view, the three generational heap plus the Large Object Heap are logically distinct heaps, adding that up to four. This implementation detail starts to matter when you allocate too much.
Another one that you can't entirely ignore in managed code is the heap that stores static variables. It is associated with the AppDomain, static variables live as long as the AppDomain lives. Commonly named "loader heap" in .NET literature. It actually consists of 3 heaps (high frequency, low frequency and stub heap), jitted code and type data is stored there too but that's getting to the nitty gritty.
Further down the ignore list are the heaps used by native code. Two of them are readily visible from the Marshal class. There's a default process heap, Windows allocates from it, so does Marshal.AllocHGlobal(). And there's a separate heap where COM stores data, Marshal.AllocCoTaskMem() allocates from it. Lastly any native code you interop with will have its own heap for its runtime support. The number of heaps used by that kind of code is bounded only by the number of native DLLs that get loaded into your process. All of these heaps exist, you barely ever deal with them directly.
So, 10 heaps minimum.
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
