一、为什么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一起使用处理单线程可取消的任务。