private boolean coalesceEvent(AWTEvent e, int priority) {

        if (e instanceof PaintEvent) {
            return coalescePaintEvent((PaintEvent)e);//对paintevent进行一轮合并处理，导致同一重量级组件的多次paintevent被合并为一个paintevent等待dispatch。以提高效率
        }

然后EDT中在Component.dispatchImpl中委托给wcomponentpeer处理。

public abstract class Component{

dispatchEventImpl{
/*
         * 9. Allow the peer to process the event.
         * Except KeyEvents,
         */
            if (tpeer != null) {
                tpeer.handleEvent(e);
            }
       

public abstract class WComponentPeer{

public void handleEvent(AWTEvent e) {

switch(id) {
            case PaintEvent.PAINT:
                // Got native painting
                paintPending = false;
                // Fallthrough to next statement
            case PaintEvent.UPDATE:
                // Skip all painting while layouting and all UPDATEs
                // while waiting for native paint
                if (!isLayouting && ! paintPending) {
                    paintArea.paint(target,shouldClearRectBeforePaint());
                }
                return;
            default:
            break;
        }

Peer处理过程中将利用自身维护的PaintArea进行重画区域的优化，并执行子组件paint回调。
/**
     * Invokes paint and update on target Component with optimal
     * rectangular clip region.
     * If PAINT bounding rectangle is less than
     * MAX_BENEFIT_RATIO times the benefit, then the vertical and horizontal unions are
     * painted separately.  Otherwise the entire bounding rectangle is painted.
     *
     * @param   target Component to <code>paint</code> or <code>update</code>
     * @since   1.4
     */
    public void paint(Object target, boolean shouldClearRectBeforePaint) {
        Component comp = (Component)target;
~~~
        if (ra.paintRects[HORIZONTAL] != null && ra.paintRects[VERTICAL] != null) {
            Rectangle paintRect = ra.paintRects[HORIZONTAL].union(ra.paintRects[VERTICAL]);
            int square = paintRect.width * paintRect.height;
            int benefit = square - ra.paintRects[HORIZONTAL].width
                * ra.paintRects[HORIZONTAL].height - ra.paintRects[VERTICAL].width
                * ra.paintRects[VERTICAL].height;
            // if benefit is comparable with bounding box
            if (MAX_BENEFIT_RATIO * benefit < square) {
                ra.paintRects[HORIZONTAL] = paintRect;
                ra.paintRects[VERTICAL] = null;
            }
        }
        for (int i = 0; i < paintRects.length; i++) {
            if (ra.paintRects[i] != null
                && !ra.paintRects[i].isEmpty())
            {
                // Should use separate Graphics for each paint() call,
                // since paint() can change Graphics state for next call.
                Graphics g = comp.getGraphics();
                if (g != null) {
                    try {
                        g.setClip(ra.paintRects[i]);
                        if (i == UPDATE) {
                            updateComponent(comp, g);
                        } else {
                            if (shouldClearRectBeforePaint) {
                                g.clearRect( ra.paintRects[i].x,
                                             ra.paintRects[i].y,
                                             ra.paintRects[i].width,
                                             ra.paintRects[i].height);
                            }
                            paintComponent(comp, g);
                        }
                    } finally {
                        g.dispose();
                    }
                }
            }
        }
    }
若为true,在SwingPaintEventDispatcher.createPaintEvent，
if (component instanceof RootPaneContainer) {//如果是顶层容器
            AppContext appContext = SunToolkit.targetToAppContext(component);
            RepaintManager rm = RepaintManager.currentManager(appContext);
            if (!SHOW_FROM_DOUBLE_BUFFER ||//参数swing.showFromDoubleBuffer控制，默认true确定swing//是否会考虑双缓存支持
                  !rm.show((Container)component, x, y, w, h)) {
                rm.nativeAddDirtyRegion(appContext, (Container)component,
                                        x, y, w, h);
            }
return new IgnorePaintEvent(component, PaintEvent.PAINT,
                                        new Rectangle(x, y, w, h));//返回一个将被忽略的假事件提交

如果SHOW_FROM_DOUBLE_BUFFER 考虑双缓存支持，将进行rm.show，其交给getPaintManager().show，这时的paintmanager是经过了前面所说的几个参数选择的，也就是说，考虑当前是否当前正使能双缓存doubleBufferingEnabled，是否不使用本地双缓存nativeDoubleBuffering， BUFFER_STRATEGY_TYPE是否指定了每窗口缓存的双缓存支持策略，如果没有指定策略是否或本地windows系统环境没有开启vista dwm效果，如果都满足将使用BufferStrategyPaintManager，借由swing提供每窗口双缓存机制，检查swing记录中是否具有有效缓存，若存在则会要求该区直接拷贝flip即可，如果没有成功执行双缓存拷贝，则将加入Repaintmanager重画区域进行swing模式的重画。
顶层容器除了在对等体发过消息后处理paint，也具有自己的repaint方法去主动创造绘画时机。
public void repaint(long time, int x, int y, int width, int height) {
       if (RepaintManager.HANDLE_TOP_LEVEL_PAINT) {//属性swing.handleTopLevelPaint确定，默认true
            RepaintManager.currentManager(this).addDirtyRegion(
                              this, x, y, width, height);
        }
        else {
            super.repaint(time, x, y, width, height);
        }
    }
这里的repaint将首先确定RepaintManager.HANDLE_TOP_LEVEL_PAINT-如果不支持将委托给Component.repaint，形成PaintEvent并进行提交走AWT模式。支持的话将促使RepaintManager加入重画区后通过调度走SWING模式。SWING模式就是走RepaintManager的方式。自身的repaint不会去考虑每窗口双缓存直接拷贝区域，因为这时的需求就是要求重新绘画。
轻量级swing组件在自己的repaint方法去主动创造绘画时机。
JComponent.Repaint{RepaintManager.currentManager(this).addDirtyRegion}走SWING模式处理。
SWING模式都是借由RepaintManager来安排绘画，它维护了一个几何区域并负责重画的框架。外界总是要求先加入RepaintManager重绘区，在加入的同时激发起一个调度重画的
SunToolkit.getSystemEventQueueImplPP(context).
                postEvent(new InvocationEvent(Toolkit.getDefaultToolkit(),
                                              processingRunnable))

public class MyApplication {
public static void main(String[] args) {
   JFrame f = new JFrame("Labels");
   // 在这里将各组件 
   // 加入到主框架…… 
   f.pack(); 
   f.show(); 
   // 不要再做任何GUI工作…… 
   } 
}

上面所示的代码全部在“main”线程中运行。对f.pack()的调用使得JFrame以下的组件都被具现化。这意味着，f.show()调用是不安全的且应该在事件派发线程中执行。尽管如此，只要程序还没有一个看得到的GUI，JFrame或它的里面的组件就几乎不可能在f.show()返回前收到一个paint()调用。因为在f.show()调用之后不再有任何GUI代码，于是所有GUI工作都从主线程转到了事件派发线程，因此前面所讨论的代码实际上是线程安全的。

一个applet的GUI可以在init()方法中构造和显示：现有的浏览器都不会在一个applet的init()和start()方法被调用前绘制它。因而，在一个applet的init()方法中构造GUI是安全的，只要你不对applet中的对象调用show()或setVisible(true)方法。
要顺便一提的是，如果applet中使用了Swing组件，就必须实现为JApplet的子类。并且，组件应该添加到的JApplet内容窗格（content pane）中，而不要直接添加到JApplet。对任何applet，你都不应该在init()或start()方法中执行费时的初始化操作；而应该启动一个线程来执行费时的任务。

下述JComponent方法是安全的，可以从任何线程调用：repaint()、revalidate()、和invalidate()。repaint()和revalidate()方法为事件派发线程对请求排队，并分别调用paint()和validate()方法。invalidate()方法只在需要确认时标记一个组件和它的所有直接祖先。

监听者列表可以由任何线程修改：调用addListenerTypeListener()和removeListenerTypeListener()方法总是安全的。对监听者列表的添加/删除操作不会对进行中的事件派发有任何影响。

注意：revalidate()和旧的validate()方法之间的重要区别是，revalidate()会缓存请求并组合成一次validate()调用。这和repaint()缓存并组合绘制请求类似。
大多数初始化后的GUI工作自然地发生在事件派发线程。一旦GUI成为可见，大多数程序都是由事件驱动的，如按钮动作或鼠标点击，这些总是在事件派发线程中处理的。
不过，总有些程序需要在GUI成为可见后执行一些非事件驱动的GUI工作。比如：

在成为可用前需要进行长时间初始化操作的程序：这类程序通常应该在初始化期间就显示出GUI，然后更新或改变GUI。初始化过程不应该在事件派发线程中进行；否则，重绘组件和事件派发会停止。尽管如此，在初始化之后，GUI的更新/改变还是应该在事件派发线程中进行，理由是线程安全。

必须响应非AWT事件来更新GUI的程序：例如，想象一个服务器程序从可能运行在其他机器上的程序得到请求。这些请求可能在任何时刻到达，并且会引起在一些可能未知的线程中对服务器的方法调用。这个方法调用怎样更新GUI呢？在事件派发线程中执行GUI更新代码。

SwingUtilities类提供了两个方法来帮助你在事件派发线程中执行代码：

invokeLater()：要求在事件派发线程中执行某些代码。这个方法会立即返回，不会等待代码执行完毕。

invokeAndWait()：行为与invokeLater()类似，除了这个方法会等待代码执行完毕。一般地，你可以用invokeLater()来代替这个方法。

下面是一些使用这几个API的例子。请同时参阅《The Java Tutorial》中的“BINGO example”，尤其是以下几个类：CardWindow、ControlPane、Player和OverallStatusPane。

使用invokeLater()方法

你可以从任何线程调用invokeLater()方法以请求事件派发线程运行特定代码。你必须把要运行的代码放到一个Runnable对象的run()方法中，并将此Runnable对象设为invokeLater()的参数。invokeLater()方法会立即返回，不等待事件派发线程执行指定代码。这是一个使用invokeLater()方法的例子：

Runnable doWorkRunnable = new Runnable() {
    public void run() { doWork(); }
};
SwingUtilities.invokeLater(doWorkRunnable);

使用invokeAndWait()方法

invokeAndWait()方法和invokeLater()方法很相似，除了invokeAndWait()方法会等事件派发线程执行了指定代码才返回。在可能的情况下，你应该尽量用invokeLater()来代替invokeAndWait()。如果你真的要使用invokeAndWait()，请确保调用invokeAndWait()的线程不会在调用期间持有任何其他线程可能需要的锁。
这是一个使用invokeAndWait()的例子：

void showHelloThereDialog() 
        throws Exception {
    Runnable showModalDialog = new 
      Runnable() {
        public void run() {
            JOptionPane.showMessageDialog(
               myMainFrame, "Hello There");
        }
    };
    SwingUtilities.invokeAndWait
       (showModalDialog);
}

类似地，假设一个线程需要对GUI的状态进行存取，比如文本域的内容，它的代码可能类似这样：

void printTextField() throws Exception {
    final String[] myStrings = 
       new String[2];

    Runnable getTextFieldText = 
      new Runnable() {
        public void run() {
            myStrings[0] = 
               textField0.getText();
            myStrings[1] = 
               textField1.getText();
        }
    };
    SwingUtilities.invokeAndWait
      (getTextFieldText);

    System.out.println(myStrings[0] 
                       + " " + myStrings[1]);
}

如果你能避免使用线程，最好这样做。线程可能难于使用，并使得程序的debug更困难。一般来说，对于严格意义下的GUI工作，线程是不必要的，比如对组件属性的更新。
不管怎么说，有时候线程是必要的。下列情况是使用线程的一些典型情况：

执行一项费时的任务而不必将事件派发线程锁定。例子包括执行大量计算的情况，会导致大量类被装载的情况（如初始化），和为网络或磁盘I/O而阻塞的情况。

重复地执行一项操作，通常在两次操作间间隔一个预定的时间周期。

要等待来自客户的消息。

你可以使用两个类来帮助你实现线程：

SwingWorker：创建一个后台线程来执行费时的操作。

Timer：创建一个线程来执行或多次执行某些代码，在两次执行间间隔用户定义的延迟。

使用SwingWorker类

SwingWorker类在SwingWorker.java中实现，这个类并不包含在Java的任何发行版中，所以你必须单独下载它。
SwingWorker类做了所有实现一个后台线程所需的肮脏工作。虽然许多程序都不需要后台线程，后台线程在执行费时的操作时仍然是很有用的，它能提高程序的性能观感。
SwingWorker's get() method. Here's an example of using SwingWorker:
要使用SwingWorker类，你首先要实现它的一个子类。在子类中，你必须实现construct()方法还包含你的长时间操作。当你实例化SwingWorker的子类时，SwingWorker创建一个线程但并不启动它。你要调用你的SwingWorker对象的start()方法来启动线程，然后start()方法会调用你的construct()方法。当你需要construct()方法返回的对象时，可以调用SwingWorker类的get()方法。这是一个使用SwingWorker类的例子：

...// 在main方法中：
    final SwingWorker worker = 
      new SwingWorker() {
        public Object construct() {
            return new 
               expensiveDialogComponent();
        }
    };
    worker.start();

...// 在动作事件处理方法中:
    JOptionPane.showMessageDialog
        (f, worker.get());

当程序的main()方法调用start()方法，SwingWorker启动一个新的线程来实例化ExpensiveDialogComponent。main()方法还构造了由一个窗口和一个按钮组成的GUI。
当用户点击按钮，程序将阻塞，如果必要，阻塞到ExpensiveDialogComponent创建完成。然后程序显示一个包含ExpensiveDialogComponent的模式对话框。你可以在MyApplication.java找到整个程序。

使用Timer类

Timer类通过一个ActionListener来执行或多次执行一项操作。你创建定时器的时候可以指定操作执行的频率，并且你可以指定定时器的动作事件的监听者（action listener）。启动定时器后，动作监听者的actionPerformed()方法会被（多次）调用来执行操作。
定时器动作监听者（action listener）定义的actionPerformed()方法将在事件派发线程中调用。这意味着你不必在其中使用invokeLater()方法。
这是一个使用Timer类来实现动画循环的例子：

public class AnimatorApplicationTimer 
  extends JFrame implements 
  ActionListener {
    ...//在这里定义实例变量
    Timer timer;

    public AnimatorApplicationTimer(...) {
        ...
        // 创建一个定时器来  
        // 来调用此对象action handler。
        timer = new Timer(delay, this);
        timer.setInitialDelay(0);
        timer.setCoalesce(true);
        ...
    }

    public void startAnimation() {
        if (frozen) {
            // 什么都不做。应用户要求 
            // 停止变换图像。
        } else {
            // 启动（或重启动）动画！
            timer.start();
        }
    }

    public void stopAnimation() {
        // 停止动画线程。
        timer.stop();
    }

    public void actionPerformed
      (ActionEvent e) {
        // 进到下一帧动画。
        frameNumber++;

        // 显示。
        repaint();
    }
    ...
}

在一个线程中执行所有的用户界面代码有这样一些优点：

组件开发者不必对线程编程有深入的理解：像ViewPoint和Trestle这类工具包中的所有组件都必须完全支持多线程访问，使得扩展非常困难，尤其对不精通线程编程的开发者来说。最近的一些工具包如SubArctic和IFC，都采用和Swing类似的设计。

事件以可预知的次序派发：invokeLater()排队的runnable对象从鼠标和键盘事件、定时器事件、绘制请求的同一个队列派发。在一些组件完全支持多线程访问的工具包中，组件的改变被变化无常的线程调度程序穿插到事件处理过程中。这使得全面测试变得困难甚至不可能。

更低的代价：尝试小心锁住临界区的工具包要花费实足的时间和空间在锁的管理上。每当工具包中调用某个可能在客户代码中实现的方法时（如public类中的任何public和protected方法），工具包都要保存它的状态并释放所有锁，以便客户代码能在必要时获得锁。当控制权交回到工具包，工具包又必须重新抓住它的锁并恢复状态。所有应用程序都不得不负担这一代价，即使大多数应用程序并不需要对GUI的并发访问。