特别注意：按java给出的Focus实现规范，jre1.7保证实现如下几点：

1.       Focus_Gained,Focus_Lost事件的序列。即如果在EDT中，应用程序查询currentFocusOwner，=A，此后=B，则中间一定按顺序收到A Lost，B Gain.这主要通过DefaultKeyboardFocusManager.dispatchEvent时，尤其是处理Gained(PreparedFocusGained)时，如果发现currentFocusOwner!=null，说明尚未得到Lost，则会主动生成一个Lost发布，处理后继续处理Gained。

2.       如果是在同一个重量级组件间做轻量级组件间切换，每一个focus event实例上可以获取到准确的opposite，source.这主要通过DefaultKeyboardFocusManager.dispatchEvent和KeyboardFocusManager.retargetEvent时，主动控制纠正可能的不准确的source,opposite。

3.       Focus Event支持temporary应用，尤其体现在当整个window失去焦点，当再次获取焦点时将恢复此window的最后聚焦组件。应用程序查询focus event.isTemporary==true时，则可以确信该组件按既有逻辑很快将恢复焦点。这主要通过DefaultKeyboardFocusManager.dispatchEvent和KeyboardFocusManager.retargetEvent时，对temporary做了充分的考虑控制。

4.       KeyEvent的处理符合规范流程：

a.       根据request时间戳缓存。

b.       解除缓存时首先KeyboardFocusManager.isProxyActive（KEYEVENT），考虑是否交给本地系统代理处理。

c.       否则KeyboardFocusManager.注册keyEventDispatchers接手处理。

d.       发布该keyevent给对应component进行处理，其中分为如下阶段：

1.       Allow the Toolkit to pass this to AWTEventListeners.注册在toolkit下的AWTEventListeners得到处理。

2.       KeyboardFocusManager.processKeyEvent用来处理焦点遍历(TAB等)。

3.       Pre-process any special events before delivery。对KEY_PRESSED，KEY_RELEASED，组件的容器有机会preProcessKeyEvent。

4.       组件的对应Key(Press,Typed,~~)Listener进行处理。

e.       KeyboardFocusManager.注册keyEventPostProcessors接手处理。

f.        组件peer得到机会处理。

在其上1，2，3点的实现中，Jre1.7版本充分考虑了跨平台性：比如Windows系统，如果仅仅是拖动滚动条是不会发出FocusEvent，而其他系统就会发出temporary的FocusEvent；有些系统在重量级对等体间切换可以提供准确的opposite，但是有些系统则不提供。而jre1.7在实现上融合了各个系统的情况，给出了全面判断并针对性地处理，保证了跨平台的Focus规范表现。

1.       在Jre1.7版本中，KeyboardFocusManager，DefaultKeyboardFocusManager这两个类,与Component, WComponentPeer类一起完成了focus的主要逻辑实现。

DefaultKeyboardFocusManager是前者的系统默认实现。其单例注册在appcontext中,如果需要，程序员可以替代它，以扩展focus的逻辑实现。

appcontext.put(KeyboardFocusManager.class, new SelfKeyboardFocusManager());

2.       Component中提供了requestFocus方法。而各个组件在初始化时都会安装默认的Listener。当这些Listener收到适当的事件通知后（比如mouse_press）即会调用这个方法。该方法首先判断该组件是否focusable，组件所依托窗口是否focusable，当前聚焦组件的InputVerifier是否验收输入等等，判断通过后请求重量级组件容器的peer.requestFocus。WComponentPeer中提供该requestFocus方法。该方法首先调用native processSynchronousLightweightTransfer，其会调用KeyboardFocusManager .processSynchronousLightweightTransferr，作用是如果当前request组件的重量级组件容器正对应当前底层系统的聚焦组件，而且当前没有任何切换焦点的heavyweightRequests，这时将直接切换focus变量KeyboardFocusManager.focusOwner。

如果上述调用没有顺利完成并返回true，则会调用native _requestFoucs。该方法会调用KeyboardFocusManager .shouldNativelyFocusHeavyweight，其作用就是完成request登记，并在登记时间戳以正确缓存处理后续进入EDT的Keyevent处理。

Request登记的结构为KeyboardFocusManager.heavyweightRequests=

LinkedList< HeavyweightFocusRequest >

-- HeavyweightFocusRequest{

Component heavyweight;

LinkedList<LightweightFocusRequest> lightweightRequests，登记方式分为3种:

a. 如果发出requestFocus的组件的重量级组件容器正对应当前底层系统的聚焦组件，而且当前没有任何切换焦点的heavyweightRequest,则增加一个heavyweightRequest并向Post-Qqeue post focus-event。

b. 如果发出requestFocus组件的重量级组件容器不对应当前底层系统的聚焦组件，而且当前没有任何切换焦点的heavyweightRequest；或者当前存在切换焦点的heavyweightRequest，而最后一个heavyweightRequest. Heavyweight!=当前request组件的重量级组件容器，则要增加一个heavyweightRequest，并同步通知底层系统进行重量级对等组件的focus切换。

c. 如果当前存在切换焦点的heavyweightRequest，而且最后一个heavyweightRequest. Heavyweight==当前requestFocus的组件的重量级组件容器，则直接在request.lightweightRequests追加一个LightweightFocusRequest。

3.       EDT在逐个处理AWTEvent时，委托给EventQueue.dispatchEvent，继而委托给Component. dispatchEventImpl,该方法顺序执行下面的代码片段：

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～·

/* focusManagerIsDispatching标志了该event;如果==true意味着该event不会交由KeyboardManager进行retarget及dispatch。而这两个动作主要完成的功能就是刷新java的全局focus变量。因此可以想象focusManagerIsDispatching==true的Focus_event是focus发生切换后的event，而focusManagerIsDispatching==false的是PrepareFocusEvent。*/

            if (!e.focusManagerIsDispatching) {//----------PrepareFocusEvent

            // Invoke the private focus retargeting method which provides

            // lightweight Component supportF

            /*通过retargetFocus，处理之前注册的request请求，最终激发出合适的CausedFocusEvent，交给下面的dispatch.

 */

            if (e.isPosted) {

                e = KeyboardFocusManager.retargetFocusEvent(e);

                e.isPosted = true;

            }

            // Now, with the event properly targeted to a lightweight

            // descendant if necessary, invoke the public focus retargeting

            // and dispatching function

/*通过dispatch给注册的DefaultKeyboardFocusManager,最终更新了java的全局focus变量

 */

            if (KeyboardFocusManager.getCurrentKeyboardFocusManager().

                dispatchEvent(e))

            {

                return;

            }

        }

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～·

4.       总之：

a. 轻量级组件的Mouse_Press Listener会requestFocus。request通过必要条件检查后会在KeyboardFocusManager.heavyweightRequests缓存列表登记，同时在一个列表中登记一个时间戳marker=当前系统时间。

b. 每一个KeyEvent都有一个发生时间when，这个发生时间认为是AWT-Windows loop底层event形成KeyEvent的时间。EDT在调用KeyboardFocusManager 。dispatchEvent处理一个KeyEvent时只要发现when晚于时间戳缓存列表中登记的第一个时间戳，就充分说明这是在某焦点切换请求发出后发生的键盘事件，则不应该将这个KeyEvent target到当前全局focus变量，因而这时暂将此KeyEvent缓存在另一个列表。

c. 根据前面的分析，在requestFocus时有3种情况，一种是新增heavyweightRequest，同时post给post-queue一个FocusEvent，一种是新增heavyweightRequest，同时因为要求底层系统切换重量级对等体而awt-loop到一个FocusEvent，这两种情况的request都在列表中期待对应FocusEvent到来再切换焦点。从登记时间戳开始，被awt-loop到的KeyEvent进入EDT时都将缓存下来，而一段时间后当期待的FocusEvent从post-queue进入event-queue并要在EDT中处理时，有充分的条件可以判断出此后再进入EDT的KeyEvent，都至少是request登记时间戳后发生的，则这时可以完成此request-删除该heavyweightRequest缓存条目，做focus实际切换，并将缓存的KeyEvent 及时间戳记录处理掉。而第3种情况是在requestFocus时可以在最末一个heavyweightRequest上直接追加LightWeightReuquest，那么当该heavyweightRequest期待的FocusEvent到来时，按前面所述处理完该request,再将后续LightWeightRequest保存引用到一个全局变量KeyboardFocusManager.currentLightweightRequests,再将此刻为止awt-loop至的post-queue的所有event完全flush到event-queue,再把一个要求循环处理所有currentLightweightRequests指向的LightWeightRequests的InvocationEvent post 到event-queue之后。这样当EDT开始处理该InvocationEvent时，有充分的条件可以判断出此后再进入EDT的KeyEvent，都至少是最后一个后续LightWeightRequest登记时间戳后发生的，则这时只需按该InvocationEvent执行即可，及逐个清理LightWeightRequest完成focus切换及处理时间戳和缓存KeyEvent。如果在循环处理过程中发生对某一个组件requestFocus调用，这时会根据处理之初currentLightweightRequests中是否只有单独1个request来确定能否processSynchronousLightweightTransferr，即如果有多个，则这时禁止processSynchronousLightweightTransferr以防止破坏了切换焦点的顺序。

d. 重量级组件不需要在Mouse_Press Listener request Focus，当被进行Mouse Press时，底层系统分发一个Focus Event，当进入EDT处理时，在jre1.7中通过KeyboardFocusManager.retargetUnexpectedFocusEventretarget，首先逐个剔除request后进行期待匹配(针对可能的底层分发-post-queue-event-queue中间环节Event的遗漏等例外情形)，如果最后没有一个request匹配，则直接形成CausedFocusEvent交给后继dispatch完成焦点切换。更确切地说，对于jre1.7而言组件聚焦应该都通过requestFocus完成切换，不通过该方式的聚焦切换在retarget时将归属到Unexpected被处理，而重量级组件的这种聚焦正好通过unexpected完成。

5.       最后，个人认为jre1.7中存在一个可能的问题：每次dispatchEvent时都会在retargetFocusEvent里processCurrentLightweightRequests，这样不久破坏了4-c分析的时机逻辑了么？为什么要这样呢？

Java dnd拖拽实现分析纪要

既有的Swing组件都内置了拖拽的支持，是怎么样支持呢？

首先，在Windows环境的jvm进程中，一个gui程序将启动两个线程：AWT-WINDOWS（AWT）和Event-Dispatch-Thread(EDT)。AWT-WINDOWS线程不断从windows操作系统中获取GUI事件并进行初步的底层处理；其中一些事件会被包装成高级的AWTEvent置入一个地方，而EDT线程的处理过程就包括不断在的适当时机从这个地方获取这些AWTEvent并进行高级处理。

然后，拖拽的效果就是由以下几个GUI操作事件及相应程序处理完成的。

1.       拖拽开始,拖拽结束。

2.       拖拽进入（源组件/目的组件），拖拽经过（源组件/目的组件），拖拽离开（源组件/目的组件），拖拽中鼠标的移动。

3.       拖拽操作式样变换。即随键盘操作，可以指示3种操作式样：剪切式，复制式，链接式。

这些事件发生后，AWT线程即会获取到事件通知并处理，底层处理后会包装交给EDT继续处理。而处理的程序逻辑一般设计为，对于鼠标图标，会被设计为随拖拽的起始及移动的整个过程中不同事件的发生而发生变化（比如在dragover事件中可能根据当时情况将图标变为一个叉表示不能拖入）；同时，对于拖拽源组件和目的组件，随不同的事件通知也会被程序设计为产生不同的变化响应（比如，拖拽结束的事件处理中可能指令目的组件复制源组件的文字内容），从而最终实现了拖拽的效果。

最后，看一些JRE7中拖拽的实现类。

Swing的JComponent组件将一些功能委托给其成员ComponentUI代理。比如JTextField在构造方法中即会通过UIManager获得合适的TextUI实例（UIManager将根据当前look and feel设置获取）（此后JTextField的paint方法会调用该UI实例的update方法从而完成组件绘画），并调用该UI实例的installUI方法（在installUI中则包括给JTextField对象安装一些监听器，安装TransferHandler这个支持拖拽的关键成员，它包含DragHandler,DropHandler两个内部类，而这两个内部类是实现拖拽效果的核心逻辑，安装droptarget）。

Swing将ui类划分在几个包中，其中javax.swing.plaf中存放一些接口；javax.swing.plaf.basic中存放对接口的基本实现，即多种LAF的通用实现；javax.swing.plaf.metal中存放java默认LAF实现；另外还有javax.swing.plaf.multi用来实现多个LAF的综合效果实现；javax.swing.plaf.synth用来实现可通过配置xml文件更换颜色等皮肤的实现。

对于拖拽方面，BasicUI在installUI中一般会对组件安装mouseListener：

editor.addMouseListener(dragListener);

editor.addMouseMotionListener(dragListener);

该dragListener将监听发生在组件上的鼠标事件，当发现可能是新启动的拖拽鼠标动作并且组件dragEnable时，则立刻通知DragRecognitionSupport单例进行组件拖拽识别。该support单例将辨别鼠标动作本身，确认是组件拖拽开始，再通知组件的TransferHandler成员对象进行拖拽初始化，即，经其辨别headless环境和action支持后将初始化建立并委托调用TransferHandler.SwingDragGestureRecognizer的全局单例(成员包括全局单例dragsource及draghandler对象)，该实例注册拖拽识别listener及设置sourceAction,最终将通知TransferHandler.DragHandler对象的dragGestureRecognized。在该方法中，将创建transferable及初始化autoscroll；并通过dragSource全局单例完成创建DragContext,并获取及初始化DragContextPeer全局单例（给该单例注册上该component作为拖拽 trigger，以供native code可以在处理底层事件时，可以通过x,y判定是否contains，从而缩小事件处理范围），并通知DragContextPeer单例拖拽开始，而DragContextPeer单例则会调用底层native code进行进一步的处理。

此后AWT线程将通过windows-api获取到系统底层的各种拖拽事件并进行底层处理，处理过程将会随时引用DragContextPeer单例（处理逻辑包括根据trigger过滤），并最终通知该单例合适的事件通知。Peer会将这些事件封装成合适的DragEvent并提交给EDT处理，提交后将促使AWT线程模拟等待EDT处理完该事件。EDT的处理逻辑是将事件交给拖拽开始时给组件创建的DragContext处理，而该context对象的处理则会调用其dragHandler成员的对应方法进行事件处理，以及给dragSource单例相应的监听通知，最后updateCurrentCursor等，最后EDT返回到AWT,peer处理返回给native code继续处理。

当拖拽开始后，鼠标图标在一个swing组件上游晃时，首先windows会对其顶层容器（如jwindows）视作拖拽源，经native code过滤后，如果该swing组件是此次拖拽trigger（源），则DragContextPeer能得到dragover的通知，进而进行后续处理；同时从另一个方面，这个也被视作一个拖拽目的，即AWT线程还会对每次拖拽启动建立一个DropContextPeer（为将来支持并发），并调用该peer的handle事件方法，该方法会将此底层事件包装后提交给EDT并促使AWT等待；EDT处理该事件时将track到该事件发生时的顶层组件，以及事件发生的坐标位置，由顶层容器组件的LightweightDispatcher进行初步处理。这个处理将由该事件产生新事件，其event source将从container（比如JFRAME）变为精确的jcomponent(比如JTextField),同时对于eventId=dragover的事件，有可能根据具体情况再增加dragExit，dragEnter两个事件（比如对jframe窗体是dragover，但鼠标实际是从一个jtextfield到另外一个jtextfield），这些精确的事件的处理会再次回到DropContextPeer中得到对应的process。这时的process会处理本身的一些成员数据（当前context,当前droptarget等），再将事件委托给source jcomponent的droptarget进行处理（如果已安装），此时的处理将是传递给对应组件的drophandler进行处理，同时会通知droptarget的注册监听，最后initializeAutoscrolling等。drophandler在处理过程中对event可以进行accept或reject，这两个动作会再去调用dropcontext进行处理，并最终转到peer处理成员数据。最后edt返回到AWT,peer handle处理结束返回native code当前drop action值，native code继续处理。

通过以上的分析，如果需要定制swing组件的拖拽逻辑，一个比较基础的入口是transferhandler；因为所有事件的处理都将经过其两个内部类逻辑处理(DragHandler和DropHandler)；而swing包中的TransferHandler的具体实现，是这两个内部类的方法都把一些控制划分给了componet的一些属性设置或TransferHandler本身的回调方法，所以只需对组件设置合适的属性，或继承并override TransferHandler合适的方法并给此swing组件重新setTransferHandler，即可以定制新的逻辑。如果需要更深层次的定制，则需要细致考虑上述分析，选择合适的定制点。

1.重用HTTPCLIENT实例。

          一般说来，建议一个通讯组件，甚至说一个应用软件就始终维持一个HttpClient对象实例存在。但是如果你的应用很稀罕才用到它，而且还不允许这么一个实例一直存在，那么，这里强烈建议，每次在disposing 它之前，一定要显式地shut down 它的 multithreaded connection manager 。这样做是确保连接池里的connection得到释放。

2.持续连接不关闭。

httpclient总是尽量重用连接。它不要求任何配置，默认情况下就是这样。某些情况下，这可能导致连接泄漏，而耗尽资源。禁用持续连接最简单的方法是提供或扩展一个connection manager，在releaseConnection被调用的时候，这个connection manager将把connection真正关闭掉。

 HTTP提供HTTP 100 (Continue) 状态，是指客户端发送一个“预期HTTP100”的请求header，如果服务器响应100说明接受该客户端请求，则客户端继续发送body。是啊，如果服务器通过header就能判断是否响应100还是拒绝，那么不通过这条路就直接发送body（尤其是大body）真的太浪费资源了。授权拒绝是最典型的情形了。因此强烈建议对于那些有HTTP认证要求的服务器使用“预期HTTP100”这种通讯方式。注意如果通讯要通过代理，程序员要处理可能的警告，因为一些老的HTTP1.0代理服务器不能正确处理“预期HTTP100”通讯方式。
6. 钝态连接的检查
HTTP协议规范允许客户端或服务器端不知会对方，在任意时刻都可以终止一个连接（指底层网络连接），因此这个connection就变成了钝态或者说陈旧了，反正是不能用了。在默认情况下，HttpClient 会在执行HTTP方法前检查要用的连接，看看是否是钝态。这个检查需耗时15-30ms，根据使用的jre不同而不同。关闭这个检查能带来小部分的性能提升，尤其对于小负载response这种通讯。但是关闭后可能面临底层连接已关闭的异常（服务器主动关闭但没通知客户端）。
7.Cookie 处理
如果一个应用程序，例如web spider，不需要和服务器保持会话状态，则禁用cookie会带来轻微的性能提升。