您从一个因多线程不良而几乎/实际上失败的项目中学到了什么？[关闭]

您从一个因多线程不良而几乎/实际上失败的项目中学到了什么？

有时，框架会采用某种线程模型，使事情难以正确处理一个数量级。

对于我来说，我还没有从上一次失败中恢复过来，我觉得最好不要在该框架中处理与多线程有关的任何事情。

我发现我擅长处理多线程问题，这些问题具有简单的fork / join，并且数据仅在一个方向上传播（而信号可以在圆形方向上传播）。

我无法处理GUI，其中某些工作只能在严格序列化的线程（“主线程”）上完成，而其他工作只能在除主线程（“工作线程”）之外的任何线程上完成，并且数据和消息必须在N个组件之间完全传播（完整连接的图表）。

在我将该项目移交给另一个项目时，到处都有僵局问题。我听说2-3个月后，其他几位开发人员设法解决了所有僵局问题，以至于可以将其交付给客户。我从未设法找出我所缺少的知识。

关于项目的一些事情：消息ID（描述事件含义的整数值，可以将其发送到另一个对象的消息队列中，而与线程无关，而已）达到数千。唯一字符串（用户消息）也有大约一千。

添加

我从另一个团队得到的最好的类比（与我的过去或现在的项目无关）是“将数据放入数据库”。（“数据库”指的是集中化和原子更新。）在分为多个视图且全部在同一“主线程”上运行且所有非GUI繁重工作都在单个工作线程中完成的GUI中，应用程序的数据应可以将其存储在一个像数据库一样的单一文件中，并让“数据库”处理涉及非平凡数据依赖项的所有“原子更新”。GUI的所有其他部分仅处理屏幕绘图，而没有其他内容。UI部分可能会缓存内容，并且如果设计正确，用户将不会注意到它是否过时了不到一秒钟。此“数据库”也称为“文档” 在文档视图体系结构中。不幸的是-不，我的应用程序实际上将所有数据存储在“视图”中。我不知道为什么会这样。

会员贡献者：

（贡献者不需要使用真实/个人示例。如果您自己认为可信的轶事示例，也欢迎他们提供经验教训。）

我最喜欢的课程–来之不易！–在多线程程序中，调度程序是讨厌您的狡猾猪。如果事情出了问题，它们将会以意外的方式发生。弄错任何事情，您将追逐奇怪的heisenbug（因为您添加的任何工具都会改变计时，并为您提供不同的运行方式）。

解决此问题的唯一明智的方法是将所有线程处理严格地合并为一小段代码，以使其正常运行，并且对于确保正确持有锁（以及全局固定的获取顺序）也非常保守。 。最简单的方法是在线程之间不共享内存（或其他资源），除非消息必须异步。这样，您就可以采用线程无关的样式编写其他所有内容。（奖金：扩展到集群中的多台计算机要容易得多。）

这是我现在可以想到的一些基本课程（不是从项目失败中获得，而是从实际项目中看到的实际问题中得出）：

• 保留共享资源时，请尝试避免任何阻塞呼叫。常见的死锁模式是线程获取互斥锁，进行回调，在同一互斥锁上进行回调。
• 用互斥/关键部分保护对任何共享数据结构的访问（或使用无锁的部分-但不要自己动手！）
• 不要假设原子性-使用原子API（例如InterlockedIncrement）。
• 有关正在使用的库，对象或API的线程安全性的RTFM。
• 利用可用的同步原语，例如事件，信号量。（但是在使用它们时要格外注意，您知道自己处于良好状态-我已经看到了许多以错误状态表示事件的示例，这些事件会丢失事件或数据）
• 假设线程可以同时执行和/或以任何顺序执行，并且上下文可以随时在线程之间切换（除非在做出其他保证的OS下）。

• 您的整个GUI项目应仅从主线程调用。基本上，您不应该在GUI中添加单个（.net）“调用”。多线程应该卡在处理数据访问速度较慢的单独项目中。

我们继承了一个部分，其中GUI项目使用了十几个线程。除了问题，它什么都没有。死锁，赛车问题，跨线程GUI调用...

Java 5和更高版本具有Executors，旨在使处理多线程fork-join风格程序的工作变得更轻松。

使用那些，将消除很多痛苦。

（是的，这是我从一个项目中学到的：））

我在硬实时嵌入式系统方面有背景。您无法测试是否存在多线程导致的问题。（您有时可以确认存在）。代码必须证明是正确的。因此，围绕所有线程交互的最佳实践。

• ＃1规则：吻-如果不需要线程，请不要旋转。尽可能序列化。
• ＃2规则：不要打破＃1。
• ＃3如果您无法通过审查证明它是正确的，那是不正确的。

我去年参加的关于多线程课程的类比非常有帮助。线程同步就像交通信号一样，保护交叉路口（数据）不被两个汽车（线程）同时使用。许多开发人员犯的错误是，在整个城市的大部分地方都把红色的信号灯点亮，让一辆汽车通过，因为他们认为弄清楚他们需要的确切信号太困难或危险。当流量很小时，这可能会很好地工作，但是随着应用程序的增长，它会导致陷入僵局。

从理论上我已经知道了这一点，但是在那堂课之后，类比的确在我心中震撼了，令我惊讶的是，在那之后我有多频繁地调查一个线程问题并找到一个巨大的队列，或者在写变量的过程中到处都禁用了中断只有两个线程被使用，或者互斥锁被长时间保留，可以完全避免重构。

换句话说，一些最糟糕的线程问题是由过分尝试避免线程问题引起的。

再试一次。

至少对我来说，造成差异的是实践。在完成多线程和分布式工作很多次之后，您就可以掌握它了。

我认为调试确实使它变得困难。我可以使用VS调试多线程代码，但是如果必须使用gdb的话，我真的会感到茫然。可能是我的错

正在学习更多的另一件事是无锁数据结构。

我认为，如果您指定框架，则可以真正改善此问题。例如，.NET线程池和后台工作程序实际上与QThread不同。总是有一些平台特定的陷阱。

我了解到，从较低级别的模块到较高级别的模块的回调是一个巨大的弊端，因为它们会导致以相反的顺序获取锁。