我正在到处应用我新发现的线程知识并获得很多惊喜
示例：
我用线程在一个 大批。结果每次都不一样 时间。问题是我所有的 线程正在更新相同的 变量且未同步。
旁注：
（我将程序 thread_add.java 重命名为 thread_random_number_generator.java:-)
【问题讨论】：
标签： multithreading language-agnostic
在多线程环境中，您必须注意同步，这样两个线程就不会因为同时执行修改而破坏状态。否则，您的代码中可能会出现竞争条件（例如，请参阅infamous Therac-25 accident。）您还必须调度线程来执行各种任务。然后，您必须确保您的同步和调度不会导致多个线程无限期地相互等待的死锁。
同步
像增加计数器这样简单的事情需要同步：
counter += 1;
假设这一系列事件：
counter 初始化为 0counter到cpu(0)counter 到 cpu (0)counter
counter 从 cpu 写回内存 (1)counter
counter 从 cpu 写回内存 (1)此时counter 为1，但两个线程都尝试增加它。必须通过某种锁定机制来同步对计数器的访问：
lock (myLock) {
counter += 1;
}
只允许一个线程执行锁定块内的代码。执行此代码的两个线程可能会导致以下事件序列：
myLock
myLock 但必须等待counter到cpu(0)counter
counter 从 cpu 写回内存 (1)myLock
myLock
counter 到 cpu (1)counter
counter 从 cpu 写回内存 (2)myLock
此时counter 为2。
调度
调度是同步的另一种形式，您必须使用线程同步机制（如事件、信号量、消息传递等）来启动和停止线程。这是 C# 中的一个简化示例：
AutoResetEvent taskEvent = new AutoResetEvent(false);
Task task;
// Called by the main thread.
public void StartTask(Task task) {
this.task = task;
// Signal the worker thread to perform the task.
this.taskEvent.Set();
// Return and let the task execute on another thread.
}
// Called by the worker thread.
void ThreadProc() {
while (true) {
// Wait for the event to become signaled.
this.taskEvent.WaitOne();
// Perform the task.
}
}
您会注意到对this.task 的访问可能没有正确同步，工作线程无法将结果返回给主线程，并且无法发出终止工作线程的信号。所有这些都可以在更详细的示例中得到纠正。
死锁
一个常见的死锁示例是当您有两个锁并且您不小心如何获取它们时。在某一时刻，您在lock2 之前获得了lock1：
public void f() {
lock (lock1) {
lock (lock2) {
// Do something
}
}
}
在另一点上，您在lock1 之前获得了lock2：
public void g() {
lock (lock2) {
lock (lock1) {
// Do something else
}
}
}
让我们看看这可能会如何死锁：
f
lock1
g
lock2
lock1 但必须等待lock2 但必须等待此时线程 A 和 B 正在互相等待并死锁。
【讨论】：
有两种人不使用多线程。
1) 那些不理解这个概念并且不知道如何编程的人。 2) 那些完全理解这个概念并且知道把它做好是多么困难的人。
【讨论】：
我会做一个非常明目张胆的声明：
不要使用共享内存。
做使用消息传递。
作为一般建议，请尝试限制共享状态的数量并更喜欢更多事件驱动的架构。
【讨论】：
除了将您指向 Google 之外，我无法为您提供示例。搜索线程基础知识、线程同步，您将获得比您知道的更多的点击率。
线程的基本问题是线程彼此不了解 - 所以它们会很高兴地踩到彼此的脚趾，就像两个人试图通过一扇门一样，有时他们会一个接一个地通过，但是有时他们会同时尝试通过并且会卡住。这很难重现，难以调试，并且有时会导致问题。如果您有线程并看到“随机”失败，这可能就是问题所在。
因此需要注意共享资源。如果您和您的朋友想要一杯咖啡，但只有一个勺子，您不能同时使用它，那么你们中的一个将不得不等待另一个。用于“同步”对共享勺子的访问的技术是锁定。您确保在使用共享资源之前获得了锁定，然后再放开它。如果其他人有锁，你等到他们释放它。
下一个问题与这些锁有关，有时您的程序可能很复杂，以至于您获得了锁，然后执行其他操作，然后访问另一个资源并尝试为此获得锁-但是其他一些线程具有第二个资源，所以你坐下来等待......但是如果第二个线程正在等待你为第一个资源持有的锁......它会坐下来等待。你的应用程序就在那里。这称为死锁，两个线程都在等待对方。
这两个是绝大多数线程问题。答案通常是锁定时间越短越好，一次只持有 1 个锁定。
【讨论】：
我注意到你正在用 java 编写，并且没有其他人提到书籍，所以 Java Concurrency In Practice 应该是你的多线程圣经。
【讨论】：
-- 有哪些已知的线程问题？ --
-- 使用线程时应该注意什么？ --
在单处理器机器上使用多线程处理多个任务，其中每个任务花费大约相同的时间并不总是很有效。例如，您可能决定在程序中生成 10 个线程以处理 10 个单独的任务。如果每个任务大约需要 1 分钟的时间来处理，并且您使用 10 个线程来执行此处理，那么在整个 10 分钟内您将无法访问任何任务结果。相反，如果您只使用一个线程处理相同的任务，您将在 1 分钟内看到第一个结果，1 分钟后看到下一个结果，依此类推。如果您可以利用每个结果，而不必依赖同时准备好所有结果，那么单个 线程可能是实现程序的更好方式。
如果您在一个进程中启动大量线程，线程内务管理和上下文切换的开销可能会变得很大。处理器将花费大量时间在线程之间切换，并且许多线程将无法取得进展。此外，具有大量线程的单个进程意味着其他进程中的线程的调度频率会降低，并且不会获得合理的处理器时间份额。
如果多个线程必须共享许多相同的资源，您不太可能看到多线程应用程序带来的性能优势。许多开发人员将多线程视为某种能够自动带来性能优势的魔杖。不幸的是，多线程并不是它有时被认为是的魔杖。如果您出于性能原因使用多线程，您应该在几种不同的情况下非常密切地衡量您的应用程序的性能，而不是仅仅依靠一些不存在的魔法。
协调线程对公共数据的访问可能是一个很大的性能杀手。使用粗锁计划时，使用多线程实现良好的性能并不容易，因为这会导致低并发和等待访问的线程。或者，除非您执行一些复杂的调整，否则细粒度的锁定策略会增加复杂性并且还会降低性能。
使用多线程来利用具有多个处理器的机器在理论上听起来是个好主意，但在实践中你需要小心。要获得任何显着的性能优势，您可能需要掌握线程平衡。
-- 请举例说明。 --
例如，假设一个应用程序接收来自 网络，对这些信息进行聚合和排序，然后显示结果 在最终用户的屏幕上。
对于双核机器，将任务分成三个线程是有意义的。第一个线程处理存储传入的价格信息，第二个线程处理价格，最后一个线程处理结果的显示。
实施此解决方案后，假设您发现价格处理是迄今为止最长的阶段，因此您决定重写该线程的代码以将其性能提高三倍。不幸的是，单线程中的这种性能优势可能不会反映在整个应用程序中。这是因为其他两个线程可能无法跟上改进的线程。如果用户界面线程无法跟上更快的处理信息流，则其他线程现在必须等待系统中的新瓶颈。
是的，这个例子直接来自我自己的经验:-)
【讨论】：
不要使用全局变量
不要使用许多锁（最好不要使用 - 尽管实际上是不可能的）
不要尝试成为英雄，实施复杂困难的 MT 协议
做使用简单的范例。即将一个数组的处理共享给 n 个相同大小的切片 - 其中 n 应该等于处理器的数量
做在不同的机器上测试你的代码（使用一个、两个、多个处理器）
做使用原子操作（如InterlockedIncrement()等）
【讨论】：
要记住的最重要的事情是：你真的需要多线程吗？
【讨论】：
到目前为止，我几乎同意所有答案。
一个好的编码策略是尽可能减少或消除线程之间共享的数据量。你可以这样做：
尽量不要让多个线程竞争完全相同的 I/O“资源”，无论是磁盘文件、数据库表、Web 服务调用还是其他任何东西。当多个线程争夺同一资源时，这将导致争用。
这是一个非常人为设计的 OTT 示例。在实际应用中，您可以限制线程数以减少调度开销：
与其猜测如何分配任务，不如分析您的应用程序并隔离那些 (a) 非常慢和 (b) 可以异步完成的部分。这些都是单独线程的好候选。
以下是你应该避免的：
【讨论】：
除非确实需要，否则不要启动新线程。启动线程并不便宜，对于短期运行的任务，启动线程实际上可能比执行任务本身花费更多的时间。如果您使用 .NET，请查看内置线程池，它在很多（但不是全部）情况下都很有用。通过重用线程，降低了启动线程的成本。
编辑：关于创建线程与使用线程池（.NET 特定）的一些注意事项
一般尽量使用线程池。例外：
可能还有更多例外，我并不是说这是确定的答案。这正是我能想到的atm。
【讨论】：
我正在应用我的新发现的线程知识
[强调添加]
请记住一点知识是危险的。了解您平台的线程 API 很容易。知道为什么和当你需要使用同步是困难的部分。阅读“死锁”、“竞争条件”、“优先级反转”会让你开始理解为什么。
何时使用同步的细节既简单（共享数据需要同步）又复杂（以正确方式使用的原子数据类型不需要同步，哪些数据是真正共享的）：一生的学习和非常好的解决方案具体的。
【讨论】：
需要注意的重要事项（具有多个内核和 CPU）是cache coherency。
【讨论】：
我很惊讶没有人指出 Herb Sutter 的 Effective Concurrency 专栏。在我看来，如果你想去线程附近的任何地方，这是必读的。
【讨论】：
a) 始终只让 1 个线程负责资源的生命周期。这样线程 A 就不会删除线程 B 需要的资源 - 如果 B 拥有资源的所有权
b) 期待意外
【讨论】：
请考虑如何测试您的代码并为此留出大量时间。单元测试变得更加复杂。您可能无法手动测试您的代码 - 至少不可靠。
请考虑线程生命周期以及线程如何退出。不要杀死线程。提供一种机制，使它们能够优雅地退出。
请在您的代码中添加某种调试日志记录 - 这样您就可以在出现问题时看到您的线程在开发和生产中的行为都正确无误。
请使用一个好的库来处理线程，而不是滚动您自己的解决方案（如果可以的话）。例如。 java.util.concurrency
不要假设共享资源是线程安全的。
不要这样做。例如。使用可以为您处理线程问题的应用程序容器。使用消息传递。
【讨论】：
在 .Net 中，当我开始尝试使用多线程时，让我感到惊讶的一件事是，除了创建 UI 控件的线程之外，您无法直接从任何线程更新 UI 控件。
有一种方法可以解决这个问题，就是使用 Control.Invoke 方法来更新另一个线程上的控件，但第一次不是 100% 明显！
【讨论】：
在您开始真正的项目之前，不要误以为您了解并发的困难。
所有死锁、活锁、同步等的例子看起来都很简单，其实也很简单。但是它们会误导你，因为大家都在谈论的实现并发的“难点”是在实际项目中使用时，你无法控制一切。
【讨论】：
虽然正如一些受访者所指出的那样，您在数字总和上的初始差异可能是缺乏同步的结果，但如果您深入了解该主题，请注意，一般来说，您将无法准确地重现您在串行程序中获得的数字结果与来自同一程序的并行版本的结果。浮点算术不是严格可交换的、结合的或分配的；哎呀，它甚至没有关闭。
我想与这里的多数意见有所不同。如果您正在为具有一个或多个多核 CPU 的桌面编写多线程程序，那么您正在使用共享内存计算机并且应该处理共享内存编程。 Java 具有执行此操作的所有功能。
如果不知道更多关于您正在解决的问题类型，我会犹豫是否要写“你应该这样做”或“你不应该那样做”。
【讨论】：