blocks|key|1445303|text|线程是某些东西(即并行性和异步)的基本构建块，因此不应该被移除。然而，对于大多数人和大多数用例来说，还有您提到的更适合使用的东西，例如线程池(它提供了一种很好的方式来并行处理许多小作业，而不会通过一次产生2000个线程而使机器过载)，BackgroundWorker+(它封装了单个短暂工作的有用事件)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1445304|但仅仅因为在许多情况下，这些类更合适，因为它们可以保护程序员避免不必要的重复发明轮子、犯愚蠢的错误等等，这并不意味着Thread类已经过时。它仍然由上面提到的抽象使用，如果您需要对线程的细粒度控制，而这些更特殊的类没有涉及到，那么您仍然需要它。|1445305|同样，尽管List<T>更适合于人们使用数组的许多情况，但.NET并不禁止使用数组。原因很简单，因为您可能仍然希望构建标准库不包含的内容。|1445306|entityMap^0|39|G|0|0|5|7|T|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|U|8|@]|D|@]|E|$]]]|K|$]]

Threads are a basic building block for certain things (namely parallelism and asynchrony) and thus should not be taken away. However, for most people and most use cases there are more appropriate things to use which you mentioned, such as thread pools (which provide a nice way of handling many small jobs in parallel without overloading the machine by spawning 2000 threads at once), <code>BackgroundWorker</code> (which encapsulates useful events for a single shortlived piece of work).

But just because in many cases those are more appropriate as they shield the programmer from needlessly reinventing the wheel, doing stupid mistakes and the like, that does not mean that the Thread class is obsolete. It is still used by the abstractions named above and you would still need it if you need fine-grained control over threads that is not covered by the more special classes.

In a similar vein, <code>.NET</code> doesn't forbid the use of arrays, despite <code>List&lt;T&gt;</code> being a better fit for many cases where people use arrays. Simply because you may still want to build things that are not covered by the standard lib.

blocks|key|1971478|text|你可以把Thread类比作ADO.NET，它不是完成任务的推荐工具，但它并没有过时。其他工具构建在它的基础上，以简化工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1971479|在其他东西上使用Thread类并没有错，尤其是那些东西不能提供你需要的功能的时候。|1971480|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You could compare the Thread class to ADO.NET. It's not the recommended tool for getting the job done, but its not obsolete. Other tools build on top of it to ease the job.

Its not wrong to use the Thread class over other things, especially if those things don't provide a functionality that you need.

blocks|key|954972|text|Task和Thread是不同的抽象。如果您想对线程建模，Thread类仍然是最合适的选择。例如，如果你需要与当前线程交互，我没有看到更好的类型。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|954973|然而，正如您所指出的，.NET添加了几个专用的抽象，在许多情况下比Thread更可取。|954974|entityMap^0|0|4|5|6|S|6|0|X|6|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|I|$]]

<code>Task</code> and <code>Thread</code> are different abstractions. If you want to model a thread, the <code>Thread</code> class is still the most appropriate choice. E.g. if you need to interact with the current thread, I don't see any better types for this. 

However, as you point out .NET has added several dedicated abstractions which are preferable over <code>Thread</code> in many cases.

blocks|key|1445439|text|新的选项减少了对(昂贵的)线程的直接使用和管理。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1445440|当遇到涉及到某种并行执行的任务时，|1445441|人员会直接跳转到使用优秀的旧Thread类。|blockquote|1445442|1445443|1445444|这是一种非常昂贵且相对复杂的并行处理方式。|1445445|请注意，开销是最重要的:您不能使用完整的线程来完成一项小工作，这将适得其反。ThreadPool克服了成本，任务类克服了复杂性(异常、等待和取消)。|1445446|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Q|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

The new options make direct use and management of the (expensive) threads less frequent. 

<blockquote>
 people that, when confronted with a task that involves some kind of parallel execution, jump directly to using the good old Thread class.
</blockquote>

Which is a very expensive and relatively complex way of doing stuff in parallel. 

Note that the expense matters most: You cannot use a full thread to do a small job, it would be counterproductive. The ThreadPool combats the costs, the Task class the complexities (exceptions, waiting and canceling).

blocks|key|955511|text|Thread类不能过时，因为它显然是您提到的所有其他模式的实现细节。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|955512|但这并不是你真正的问题；你的问题是|955513|955514|是否有必要或有用的情况下，使用普通的旧线程对象而不是上述结构之一？|blockquote|955515|955516|955517|好的。正是在其中一个更高级别的构造不能满足您的需求的情况下。|955518|我的建议是，如果您发现自己处于现有的高级抽象工具不能满足您的需求的情况下，并且您希望使用线程实现解决方案，那么您应该确定您真正需要的缺少的抽象，然后使用线程实现该抽象，然后使用该抽象。|955519|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|S|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|O|$]]

The Thread class cannot be made obsolete because obviously it is an implementation detail of all those other patterns you mention.

But that's not really your question; your question is 

<blockquote>
 are there any cases when it's necessary or useful to use a plain old Thread object instead of one of the above constructs?
</blockquote>

Sure. In precisely those cases where one of the higher-level constructs does not meet your needs. 

My advice is that if you find yourself in a situation where existing higher-abstraction tools do not meet your needs, and you wish to implement a solution using threads, then you should identify the missing abstraction that you really need, and then implement that abstraction using threads, and then use the abstraction.

blocks|key|1445527|text|它不一定是过时的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1445528|多线程应用程序的问题是它们很难正确处理(通常不确定的行为、输入、输出和内部状态都很重要)，因此程序员应该将尽可能多的工作推到框架/工具上。把它抽象出来。但是，抽象的死敌是性能。|1445529|所以我的问题是，有没有必要或有用的情况下，使用普通的旧|1445530|对象，而不是上面的结构之一？|blockquote|1445531|1445532|1445533|只有在有严重的性能问题、高性能目标的情况下，我才会使用线程和锁。|1445534|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|S|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

It's not definitely obsolete.

The problem with multithreaded apps is that they are very hard to get right (often indeterministic behavior, input, output and also internal state is important), so a programmer should push as much work as possible to framework/tools. Abstract it away. But, the mortal enemy of abstraction is performance.

<blockquote>
 So my question is, are there any cases when it's necessary or useful
 to use a plain old Thread object instead of one of the above
 constructs?
</blockquote>

I'd go with Threads and locks only if there will be serious performance problems, high performance goals.

blocks|key|1971578|text|Thread类并没有过时，它在特殊情况下仍然很有用。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1971579|在我工作的地方，我们编写了一个“后台处理器”，作为内容管理系统的一部分:一个Windows服务，它监控目录、电子邮件地址和RSS提要，每当有新的东西出现时，就在它上面执行一个任务--通常是导入数据。|1971580|尝试使用线程池并不管用:它试图同时执行太多的东西，并回收磁盘，所以我们直接使用Thread类实现了我们自己的轮询和执行系统。|1971581|entityMap^0|0|6|0|0|13|6|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

The <code>Thread</code> class is not obsolete, it is still useful in special circumstances.

Where I work we wrote a 'background processor' as part of a content management system: a Windows service that monitors directories, e-mail addresses and RSS feeds, and every time something new shows up execute a task on it - typically to import the data.

Attempts to use the thread pool for this did not work: it tries to execute too much stuff at the same time and trash the disks, so we implemented our own polling and execution system using directly the <code>Thread</code> class.

blocks|key|1445598|text|为了回答“是否有必要或有用地使用普通旧thread对象的情况”的问题，我会说普通旧Thread是有用的(但不是必需的)，当你有一个长时间运行的进程，而你永远不会从不同的线程与之交互。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1445599|例如，如果您正在编写一个订阅接收来自某种消息队列的消息的应用程序，并且您的应用程序要做的不仅仅是处理这些消息，那么使用Thread将是有用的，因为线程将是自包含的(即，您不会等待它完成)，并且它不是短暂的。使用ThreadPool类更多的是为了将一堆短暂的工作项排队，并允许ThreadPool类高效地管理，将每个工作项作为新的可用线程进行处理。任务可以在你直接使用Thread的地方使用，但在上面的场景中，我认为它们不会给你带来太多好处。它们可以帮助您更轻松地与线程进行交互(上面的场景不需要)，它们还可以根据您拥有的处理器数量(这不是您想要的，所以您应该告诉任务您的东西是LongRunning的，在当前的4.0实现中，它将简单地创建一个单独的非池化线程)来确定实际应该为给定的任务集使用多少线程。|1445600|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

To answer the question of "are there any cases when it's necessary or useful to use a plain old Thread object", I'd say a plain old Thread is useful (but not necessary) when you have a long running process that you won't ever interact with from a different thread.

For example, if you're writing an application that subscribes to receive messages from some sort of message queue and you're application is going to do more than just process those messages then it would be useful to use a Thread because the thread will be self-contained (i.e. you aren't waiting on it to get done), and it isn't short-lived. Using the ThreadPool class is more for queuing up a bunch of short-lived work items and allowing the ThreadPool class manage efficiently processing each one as a new Thread is available. Tasks can be used where you would use Thread directly, but in the above scenario I don't think they would buy you much. They help you interact with the thread more easily (which the above scenario doesn't need) and they help determine how many Threads actually should be used for the given set of tasks based on the number of processors you have (which isn't what you want, so you'd tell the Task your thing is LongRunning in which case in the current 4.0 implementation it would simply create a separate non-pooled Thread).

blocks|key|5487000|text|当我需要对我旋转的线程进行计数和控制时，我总是使用Thread类。我意识到我可以使用线程池来保存我所有未完成的工作，但我从来没有找到一种好方法来跟踪当前正在完成的工作数量或状态。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5487001|相反，我创建了一个集合，并在旋转它们之后将线程放入其中-线程所做的最后一件事就是从集合中删除自己。这样，我总是可以知道有多少线程正在运行，并且我可以使用集合来询问每个线程在做什么。如果出现需要将它们全部销毁的情况，通常您必须在应用程序中设置某种“中止”标志，等待每个线程注意到它自己和自终止-在我的例子中，我可以遍历集合并依次向每个线程发出一个Thread.Abort。|5487002|在这种情况下，我还没有找到比直接使用Thread类更好的方法。正如Eric+Lippert提到的，其他类只是较高级别的抽象，当可用的高级实现不能满足您的需求时，使用较低级别的类是合适的。就像您有时需要在.NET不能满足您的实际需求时进行Thread调用一样，尽管最近有了一些“改进”，但在某些情况下Thread类始终是最佳选择。|5487003|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I've always used the Thread class when I need to keep count and control over the threads I've spun up. I realize I could use the threadpool to hold all of my outstanding work, but I've never found a good way to keep track of how much work is currently being done or what the status is.

Instead, I create a collection and place the threads in them after I spin them up - the very last thing a thread does is remove itself from the collection. That way, I can always tell how many threads are running, and I can use the collection to ask each what it's doing. If there's a case when I need to kill them all, normally you'd have to set some kind of "Abort" flag in your application, wait for every thread to notice that on its own and self-terminate - in my case, I can walk the collection and issue a Thread.Abort to each one in turn.

In that case, I haven't found a better way that working directly with the Thread class. As Eric Lippert mentioned, the others are just higher-level abstractions, and it's appropriate to work with the lower-level classes when the available high-level implementations don't meet your need. Just as you sometimes need to do Win32 API calls when .NET doesn't address your exact needs, there will always be cases where the Thread class is the best choice despite recent "advancements."

blocks|key|5487021|text|可能不是您想要的答案，但我在针对.NET微框架进行编码时一直使用线程。MF是相当精简的，不包括更高级别的抽象，当你需要从低MHz处理器中获得最后一点性能时，线程类是超级灵活的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|5487022|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Probably not the answer you were expecting, but I use Thread all the time when coding against the .NET Micro Framework. MF is quite cut down and doesn't include higher level abstractions and the Thread class is super flexible when you need to get the last bit of performance out of a low MHz CPU.

I see a lot of people in blog posts and here on SO either avoiding or advising against the usage of the <code>Thread</code> class in recent versions of C# (and I mean of course 4.0+, with the addition of <code>Task</code> &amp; friends). Even before, there were debates about the fact that a plain old thread's functionality can be replaced in many cases by the <code>ThreadPool</code> class.

Also, other specialized mechanisms are further rendering the <code>Thread</code> class less appealing, such as <code>Timer</code>s replacing the ugly <code>Thread</code> + <code>Sleep</code> combo, while for GUIs we have <code>BackgroundWorker</code>, etc.

Still, the <code>Thread</code> seems to remain a very familiar concept for some people (myself included), people that, when confronted with a task that involves some kind of parallel execution, jump directly to using the good old <code>Thread</code> class. I've been wondering lately if it's time to amend my ways. 

So my question is, are there any cases when it's necessary or useful to use a plain old <code>Thread</code> object instead of one of the above constructs?

Are there any cases when it's preferable to use a plain old Thread object instead of one of the newer constructs?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在博客文章和这里看到很多人，所以在最近的C#版本中，要么避免使用Thread类，要么建议不要使用它(当然，我指的是4.0+，增加了Task & friends)。甚至在此之前，关于普通老线程的功能在许多情况下都可以由ThreadPool类替换这一事实一直存在争议。此外，其他专门的机制进一步降低了Thread类的吸引力...

问是否存在使用普通的旧Thread对象而不是较新的构造的情况？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问是否存在使用普通的旧Thread对象而不是较新的构造的情况？EN