我在很多地方都读到过,.net Threadpool 适用于短时间跨度任务(可能不超过 3 秒)。在所有这些提及中,我没有找到不应该使用它的具体原因。
甚至有人说,如果我们在长时间的任务中使用它会导致糟糕的结果,还会导致死锁。
有人可以用简单的英语解释为什么我们不应该将线程池用于长时间跨度任务的技术原因吗?
具体来说,我什至想给出一个场景,想知道为什么ThreadPool不应该在这个场景中使用,背后有适当的理由。
场景:我需要处理数千个用户的数据。用户的处理数据是从本地数据库检索的,我需要使用该信息连接到托管在其他位置的 API,API 的响应将在处理后存储在本地数据库中。
如果我使用线程限制为 20 的 ThreadPool,是否有人可以解释我在这种情况下的陷阱?每个用户的处理时间可能在 3 秒到 1 分钟(或更多)之间。
最佳答案
线程池的要点是避免创建线程花费的时间比使用花费的时间长的情况。通过重用现有线程,我们可以避免这种开销。
缺点是线程池是共享资源:如果您使用的是线程,其他东西则不能。因此,如果您有 很多 长时间运行的任务,您最终可能会遇到线程池饥饿,甚至可能导致死锁。
不要忘记,您的应用程序代码可能不是唯一使用线程池的代码……系统代码也经常使用它。
听起来您可能想要拥有自己的生产者/消费者队列,并由少量线程处理它。或者,如果您可以使用异步 API 与您的其他服务对话,您可能会发现您计算机上的每一位处理都是短暂的。
关于c# - 为什么.net Threadpool 只用于短时间跨度的任务?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3733427/