The thread pool (by design) keeps the threads alive between calls. This means that the ThreadStatic variables will persist between calls to QueueUserWorkItem.
This behavior is also something you should not count on. The ThreadPool will (eventually, at its discretion) release threads back and let them end, and construct new threads as needed.
However, I'd question your design if you're running into problems with this. If you need specific, deterministic ThreadStatic data to be used in QueueUserWorkItem, your threading routines might be good candidates for doing the thread handling yourself. ThreadStatic and the ThreadPool aren't always a great combination - you just don't necessarily have enough control (since the ThreadPool manages the threads) to really take advantage and get benefits from ThreadStatic variables. You'll never know whether two work items will be on the same thread, different threads, and whether the threadstatic variable should be (re)initialized, etc.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…