什么是常见的并发陷阱？ [英] What are common concurrency pitfalls?

问题描述

我正在研究如何教育我们的团队并发。开发人员陷入周围并发的最常见的陷阱是什么。例如，在.Net中，关键字 static 打开了许多并发问题的大门。

不是线程安全的设计模式？

更新

这里有很多很好的答案，选择只有一个作为接受的答案。

解决方案

这个线程已经有很多好的答案和指针了，但是让我添加一件事。

$ b

不要依赖测试来查找条件和死锁 b

假设您有所有良好的开发过程：每个组件的单元测试，每个夜间构建的烟雾测试，要求每个开发者的更改在签入之前通过测试等。

这一切都很好，但它导致了一个态度好，它通过了测试套件，所以它不能是我的代码中的错误。这不会在并发编程中为您服务。实时并发错误难以重现。你可以运行一段代码，以一个竞争条件十亿次失败之前。

你必须调整你的过程，更加强调代码审查，进行你最好的心。只对并发问题进行单独的代码审查不是一个坏主意。

您必须更加重视使应用程序自行调试。也就是说，当您在测试实验室或客户的网站上遇到故障时，您需要确保捕获和记录足够的信息，以便您进行确定的事后处理，因为您能够重现错误报告的几率你的方便可以忽略不计。

你必须更加强调paranoid健全检查在代码中，以便检测到尽可能接近问题的故障，而不是50,000行代码。

是偏执狂。非常偏执。

I'm looking into educating our team on concurrency. What are the most common pitfalls developers fall into surrounding concurrency. For instance, in .Net the keyword static opens the door to a lot of concurrency issues.

Are there other design patterns that are not thread safe?

Update

There are so many great answers here it is difficult to select just one as the accepted answer. Be sure to scroll through them all for great tips.

解决方案

There are lots of good answers and pointers on this thread already, but let me add one thing.

DO NOT RELY ON TESTING TO FIND RACE CONDITIONS AND DEADLOCKS

Assuming you have all the good development processes in place: unit tests for each component, smoke tests for each nightly build, requiring each developer's changes to pass tests before checkin , etc.

All that is well and good, but it leads to an attitude of "well, it passed the test suite, so it can't be a bug in my code." which will not serve you well in concurrent programming. Real-time concurrency bugs are fiendishly hard to reproduce. You can run a piece of code with a race condition a billion times before it fails.

You will have to adjust your process to put greater emphasis on code reviews, conducted by your best minds. Having a seperate code review just for concurrency issues only is not a bad idea.

You will have to put more emphasis on making your application self-debugging. That is, when you get a failure in the test lab or at your customer's site, you need to make sure enough information is captured and logged to let you do a definitive postmortem, since the odds of your being able to reproduce the bug report at your convenience are negligible.

You will have to put more emphasis on paranoid sanity checks in your code so that a fault is detected as close to the problem as possible, and not 50,000 lines of code away.

Be paranoid. very paranoid.

这篇关于什么是常见的并发陷阱？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！