有关GUI应用程序中线程数的最佳实践

在过去,我曾与许多专门编写GUI应用程序的程序员合作过.

我得到的印象是,他们几乎普遍最小化了在他们的应用程序中使用多个线程.在某些情况下,他们似乎已经竭尽全力确保他们使用单个线程.

这是常见的吗？这是gui应用程序设计的普遍接受的哲学吗？

如果是这样,为什么？

[编辑]

有许多答案说应该最小化线程使用以降低复杂性.一般来说降低复杂性是一件好事.

但是,如果你看看对外部事件的响应至关重要的任何数量的应用程序(例如,Web服务器,任何数量的嵌入式应用程序),对线程使用的态度似乎存在差异.

我认为就Windows来说,你只限于在一个线程上发生的所有GUI操作 - 由于windows消息泵工作的方式,为了增加响应性,大多数应用程序添加至少一个额外的工作线程,否则会阻止更长时间运行的任务使ui反应迟钝.

线程从根本上来说很困难,所以用一些线程或多个线程进行思考通常会导致大量的调试工作 - 有一个引用现在就让我感到厌烦 - "如果你认为你理解线程那么你真的没有"

一般来说,GUI框架不是线程安全的.对于像Swing(Java的GUI API)这样的东西,只有一个线程可以更新UI(或者可能发生不好的事情).只有一个线程处理调度事件.如果你有多个线程更新屏幕,你可能会得到一些丑陋的闪烁和不正确的绘图.

但这并不意味着应用程序需要是单线程的.在某种情况下,您肯定不希望出现这种情况.如果单击计算pi到1000位数的按钮,则不希望UI被锁定,并且在接下来的几天内要按下按钮.这就像SwingWorker之类的东西派上用场.它有两个部分:一个doInBackground(),它在一个单独的线程中运行,一个done()由doNBackground线程完成后处理更新UI的线程调用.这允许快速处理事件,或者在后台处理需要很长时间的事件,同时仍然让单个线程更新屏幕.