ConcurrentStack 是专为高并发 LIFO 场景设计的无锁栈，不保证操作顺序可预测但确保多线程 Push/TryPop 不崩溃、不丢数据、不死锁；适用于多线程共享栈、生产者-消费者模型、避免手动加锁等场景。
ConcurrentStack<t></t> 不是「线程安全的 Stack 替代品」，而是专为高并发 LIFO 场景设计的无锁栈——它不保证操作顺序的绝对可预测性，但能确保多线程同时 Push 和 TryPop 时不会崩溃、丢数据或死锁。
什么时候必须用 ConcurrentStack<t></t> 而不是 Stack<t></t>
当你遇到以下任一情况时，Stack<t></t> 就不该再出现在线程共享上下文中：
- 多个
Task或线程同时往同一个栈里Push，哪怕只是“先塞完再统一取”——Stack<t>.Count</t>读取和Push并发会导致计数错乱，TryPeek可能返回false却实际有值 - 生产者-消费者模型中，消费者用
while (stack.Count > 0) { stack.Pop() }循环取数——这在多线程下是竞态经典陷阱：Count检查后栈被其他线程清空，Pop()直接抛InvalidOperationException - 你正在手动加
lock包裹Stack<t></t>的所有读写操作——这已违背高并发初衷，且容易漏锁、嵌套死锁；换成ConcurrentStack<t></t>后可删掉全部锁代码
TryPop 和 TryPeek 为什么不能省略 out 参数？
这两个方法的设计意图就是「不抛异常 + 显式结果反馈」。它们返回 bool 表示是否成功，而真实值通过 out 参数传出。常见错误写法：
int value = 0;
if (stack.TryPop(out value)) {
Console.WriteLine(value); // ✅ 正确
}
// ❌ 错误：value 未初始化就传入，编译不过
// if (stack.TryPop(out int value)) { ... } // 这样写语法合法，但 value 作用域仅限于 if 块内
关键点：
-
TryPop成功时才给out变量赋值；失败时该变量保持原值（所以声明时最好显式初始化） - 不要试图用
stack.Peek()（来自Stack<t></t>）去“探路”，ConcurrentStack<t></t>根本没有这个方法，只有TryPeek -
TryPeek不移除元素，但也不能保证下次TryPop一定能拿到它——因为其他线程可能已抢先弹出
PushRange 和 TryPopRange 的性能与边界行为
批量操作不是“语法糖”，而是减少 CAS 竞争次数的关键优化。尤其在吞吐密集场景（如日志缓冲、任务分发），它比循环调用 Push 快 3–5 倍。
-
PushRange(T[] array)：按数组索引升序压入，即array[0]成为新栈底，array[array.Length - 1]成为新栈顶 -
TryPopRange(T[] buffer, int startIndex, int count)：最多尝试弹出count个元素，存入buffer从startIndex开始的位置；返回实际弹出数量（可能小于count） - buffer 长度必须 ≥
startIndex + count，否则抛ArgumentException；空栈时返回 0，不修改 buffer - 若需获取全部剩余元素，建议用
stack.ToArray()（线程安全快照），而非反复TryPopRange直到返回 0
最容易被忽略的线程安全盲区：遍历与 Count
ConcurrentStack<t></t> 的 Count 是近似值——它反映的是某次快照下的大小，但无法保证你在读取后立刻执行的 TryPop 一定成功。更危险的是遍历：
- 它不支持
foreach（没有实现IEnumerable<t></t>的线程安全版本）；强行用ToArray()遍历是安全的，但得到的是调用瞬间的只读副本，不代表实时状态 -
ToArray()是 O(n) 拷贝，频繁调用会放大内存压力；若仅需判断是否为空，stack.IsEmpty比stack.Count == 0更轻量（前者是原子读，后者需计算） - 没有
Contains、IndexOf等查询方法——这不是遗漏，而是设计取舍：LIFO 场景下查存在性本身违背使用意图；真要查，应维护额外的ConcurrentDictionary<tkey bool></tkey>或ConcurrentBag<t></t>辅助结构
