是否存在使用普通的旧Thread对象而不是较新的构造的情况？
我在博客文章和这里看到很多人，所以在最近的C#版本中，要么避免使用Thread类，要么建议不要使用它(当然，我指的是4.0+，增加了Task & friends)。甚至在此之前，关于普通老线程的功能在许多情况下都可以由ThreadPool类替换这一事实一直存在争议。
此外，其他专门的机制进一步降低了Thread类的吸引力，例如Timer取代了丑陋的Thread + Sleep组合，而对于GUI，我们使用了BackgroundWorker，等等。
尽管如此，对于一些人(包括我自己)来说，Thread似乎仍然是一个非常熟悉的概念，当遇到涉及某种并行执行的任务时，他们会直接使用很好的老Thread类。我最近一直在想是不是该改正我的生活方式了。
所以我的问题是，有没有必要或有用的情况下，使用普通的旧Thread对象而不是上面的结构之一？
回答 10
Stack Overflow用户
发布于 2012-03-28 01:52:59
Thread类不能过时，因为它显然是您提到的所有其他模式的实现细节。
但这并不是你真正的问题；你的问题是
是否有必要或有用的情况下，使用普通的旧线程对象而不是上述结构之一？
好的。正是在其中一个更高级别的构造不能满足您的需求的情况下。
我的建议是，如果您发现自己处于现有的高级抽象工具不能满足您的需求的情况下，并且您希望使用线程实现解决方案，那么您应该确定您真正需要的缺少的抽象，然后使用线程实现该抽象，然后使用该抽象。
Stack Overflow用户
发布于 2012-03-28 01:49:24
线程是某些东西(即并行性和异步)的基本构建块，因此不应该被移除。然而，对于大多数人和大多数用例来说，还有您提到的更适合使用的东西，例如线程池(它提供了一种很好的方式来并行处理许多小作业，而不会通过一次产生2000个线程而使机器过载)，BackgroundWorker (它封装了单个短暂工作的有用事件)。
但仅仅因为在许多情况下，这些类更合适，因为它们可以保护程序员避免不必要的重复发明轮子、犯愚蠢的错误等等，这并不意味着Thread类已经过时。它仍然由上面提到的抽象使用，如果您需要对线程的细粒度控制，而这些更特殊的类没有涉及到，那么您仍然需要它。
同样，尽管List<T>更适合于人们使用数组的许多情况，但.NET并不禁止使用数组。原因很简单，因为您可能仍然希望构建标准库不包含的内容。
Stack Overflow用户
发布于 2012-03-28 01:51:42
Task和Thread是不同的抽象。如果您想对线程建模，Thread类仍然是最合适的选择。例如，如果你需要与当前线程交互，我没有看到更好的类型。
然而，正如您所指出的，.NET添加了几个专用的抽象，在许多情况下比Thread更可取。
https://stackoverflow.com/questions/9894821
复制相似问题
腾讯云开发者
