这取决于你正在做什么，但在大多数情况下，选项1将具有最佳性能，并且将是最易于使用的。
为了给您一个更完整的答案，我需要知道以下信息：
- 这100个线程是否都执行相同的任务？
- 这100个线程是否访问相同的数据？
- 线程处理的任务是否会有自然的停机时间（等待另一个进程完成或资源变得可用）？
- 线程处理的任务是否都尝试访问有限的资源（如硬盘或网络卡）？
- 您的计算机可以同时处理多少个线程（例如，具有超线程技术的4核处理器可以处理8个线程，而没有超线程技术的4核处理器可以处理4个线程）？
- 如果线程出现问题会发生什么？ 进程崩溃，线程被重新启动吗？
如果这些线程都执行相同的任务，则将它们放在一起会使最终用户和后期开发人员更容易管理，因为所有内容都在一个地方。
如果所有的线程都访问同一数据，那么将它们保留在同一个进程中将允许您在这些线程之间共享该数据（尽管在更改数据时要注意竞态条件），并减少内存占用。您还可以组合这些线程来访问相同块的数据，这样所有东西都可以缓存在CPU上，减少内存延迟的影响，但我不建议尝试这样做。
由于许多答案都提供了如何实现您的项目的建议，因此知道每个线程是否设计为在运行时始终充分利用CPU，或者这些是在睡眠前执行少量工作的后台任务，将有助于我们为您的情况做出正确的建议。
了解进程将在哪种硬件上运行将有助于我们为您提供正确的建议。
如果一个线程失败，会发生什么？如果一个线程一天失败一次，用户是否需要干预，停止进程并重新启动它？如果是这样，那么在其自己的进程中运行每个线程将使您受益于只失去失败的进程。
Christian Hayter的第三种选择是有道理的，但在C#中并不总是相关。
如果您查看
文档，它会说明：
操作系统ThreadId与托管线程没有固定关系，因为非托管主机可以控制托管和非托管线程之间的关系。具体而言，复杂的主机可以使用CLR Hosting API对同一操作系统线程调度许多托管线程，或将托管线程移动到不同的操作系统线程之间。
基本上，这意味着如果.NET框架认为这是一个好主意，它将池化您的线程。如果您的进程使用更多线程，则更有可能发生这种情况，而多线程进程之间的总线程数可能会保持相似。因此，我预计1个进程、100个线程的解决方案将使用比10个进程、每个进程10个线程（大约为10到40，但您必须检查）更少的总线程。
话虽如此，框架将会猜测，因此在某些情况下线程池会是更好的选择。请务必先阅读
文档，因为有一些情况下不应使用线程池。关于池的快速教程可以在
MSDN上找到。还有一个
线程讨论何时应该使用线程池。
如果您提供更多信息，我会尝试给出更准确的答案。否则，在大多数情况下，选项1（可能还有选项3）是更好的选择。
