一、为什么GUI是单线程化

传统的GUI应用程序通常都是单线程的。

1. 在代码的各个位置都须要调用poll方法来获得输入事件（这样的方式将给代码带来极大的混乱）

2. 通过一个“主事件循环（Main Event Loop）”来间接地运行应用程序的全部代码。

假设在主事件循环中调用的代码须要非常长时间才干运行完毕，那么用户界面就会“冻结”，直到代码运行完毕。这是由于仅仅有当运行控制权返回到主事件循环后，才干处理兴许的用户界面事件。

非常多尝试多线程的GUI框架的努力，最总都由于静态条件和死锁导致的稳定性问题，又回到单线程的时间队列模型的老路上。

1. 顺序事件处理

由于仅仅有唯一的线程在处理GUI任务。全部任务都不须要考虑并发且都是顺序运行，可是问题是假设在任务中运行时间过长，或导致兴许操作无法响应。（Android会提示Andorid Not Response异常）

2. Swing中的线程限制

GUI的单线程规则：组件与模型仅仅能在事件分派线程中被创建、改动和请求。

在Andorid中假设在子线程进行创建或者更新UI操作会抛出异常。

二、短期的GUI任务

GUI应用程序中，事件起源于事件线程，冒泡似得传递到达应用程序提供的监听器。假设是比較简单的改动颜色等，能够直接在事件线程中处理。

三、耗时GUI任务

由于GUI任务有线程限制，所以须要子线程处理耗时操作，通常最后还须要在子线程进行刷新。

1. 取消

2. 进度与完毕标识

3. SwingWorker

在Andorid中使用AsyncTask

四、共享数据模型

避免响应性的最简单的方式是初始化时一次性读取到内存中，这样须要考虑是否占用内存过多的问题。

1. 线程安全的数据模型

ConcurrentHashMap无法提供一致的数据快照。

CopyOnWriteArrayList同一时候获得线程安全性、一致性以及良好的响应性。

2. 分解数据模型

假设一个数据模型必须被多个线程共享，并且因为堵塞、一致性或复杂度等原因无法实现一个线程安全的模型时。能够考虑使用分解模型设计。

五、其它形式的单线程子系统

一些情况下无法避免同步或者死锁问题。比如：原生库（Native Library）要求、通过System.loadLibrary载入时，都必须放在同一个线程中运行。

将Future和newSingleThreadExecutor一起使用处理单线程可取消的任务。