display.disposeExec(new Runnable() {

              public void run() {

                     //销毁系统资源的逻辑代码

                     image.dispose();

                     …….

              }    

       });

以上方式其实也是JFace中图片资源管理（ImageRegistry、ResourceManager）能够确保Display release的时候能够彻底释放被ImageRegistry托管的图片资源。

       到这里回顾一下，SWT中资源释放的途径吧：

1、 覆写相应Component对应的dispose方法。这有别于Display的hook机制，因为其能够在Display运行期间（未被release之前）就释放掉系统资源，最好的方式。

2、 利用Display的hook机制，确保在Display被release的时候能够销毁资源。注意，请不要过多依赖此方式，因为很容易造成在Display被release之前，已经发生了系统crash的问题。
【JFace中图片资源管理－－ImageDescriptor】

       前面我们已经见过SWT中的Image和ImageData类型了，在继续下面的内容之前，我们先看一下在JFace中我们最常用来创建图片资源的一个工厂类：ImageDescriptor。在ImageDescriptor的类型说明中告诉我们，有两种使用ImageDescriptor创建图片的方式，分别通过createImage和createResource接口，“There are two ways to get an Image from an ImageDescriptor. The method createImage will always return a new Image which must be disposed by the caller. Alternatively, createResource() returns a shared Image. When the caller is done with an image obtained from createResource, they must call destroyResource() rather than disposing the Image directly.”。分析如下：

首先看一下createResource方式，ImageDescriptor是一种DeviceResourceDescriptor，后者的对外操作如下：

        /**

       *Createstheresourcedescribedbythisdescriptor

         */

        public abstract Object createResource(Device device) throws DeviceResourceException;

        /**

      *Undoeseverythingthatwasdonebyapreviouscalltocreate(...)

         */

        public abstract void destroyResource(Object previouslyCreatedObject);

这也就是说，ImageDescriptor提供了createResource / destroyResource接口来负责创建和销毁Image资源。请注意这边的一点，在孤立使用ImageDescriptor（没有配合ResourceRegistry使用，例如ImageRegistry）的时候，用户还是要负责通过调用destroyResource来释放创建的资源。

       其次来看一下createImage的方式：

              /**

*The returnedimagemustbeexplicitlydisposedusingtheimage'sdispose call.Theimagewillnotbeautomaticallygarbagecollected. */

              public Image createImage(boolean returnMissingImageOnError, Device device) {}

这也就是说，ImageDescriptor提供的createImage的方式，也需要用户来显示的销毁资源。那createImage和createResource两种方式之间的差别是什么呢？稍微分析一下ImageDescriptor的这两种创建方式的实现，我们就可以看出来差别：

1、 createImage每次都创建一个全新的图片资源（图片资源的创建是很耗时的~_~）

2、 createResource的方式采用了缓存的方式复用已经创建过的资源，并不是每次都创建一个全新的资源。这一点虽然带来了性能的提高，但是并没有解决图片资源释放的问题，倒是给开发者留下了一种假象，造成了随便使用ImageDescriptor的问题，反而造成了大量的图片资源（当然，更多的是由于调用createImage的方式造成的，因为每次都创建一个全新的图片资源）没有释放。

到现在为止，我们看到JFace已经对SWT中的图片资源的管理做了一个小的补充：提供了ImageDescriptor.createResource的方式，可以利用缓存效果，能够减少不必要的图片系统资源创建，而且效率有所提高。关于如何释放，可以参考SWT中覆写Component.dispose的方式，例如在label provider使用的图片资源，可以覆写对于provider的dispose方法，JFace框架会自动调用。


      
【JFace中图片资源管理－－ImageRegistry & ResourceManager】

下面，我们接着看一下JFace中的ImageRegistry的实现原理。

首先我们看一下JFace中的资源管理门面类（façade class）JFaceResources，我们由它来获取我们的JFace ImageRegistry：

public static ImageRegistry getImageRegistry() {

     if (imageRegistry == null) {

imageRegistry = new ImageRegistry(getResources(Display.getCurrent()));

     }

     return imageRegistry;

}

public static ResourceManager getResources(final Display toQuery) {

    ResourceManager reg = (ResourceManager)registries.get(toQuery);

    if (reg == null) {

       final DeviceResourceManager mgr = new DeviceResourceManager(toQuery);

         

               //向Display hook了销毁线程

toQuery.disposeExec(new Runnable() {

          public void run() {

             mgr.dispose();

             registries.remove(toQuery);

          }

});

    }

    return reg;

}

分析了一下ResourceManager（DeviceResourceManager）的实现，我们发现：DeviceResourceManager就是对DeviceResourceDescriptor（ImageDescriptor）进行了引用计数管理。通过JFaceResources.getResources利用了前面说的Display的hook销毁机制（注意，如果不通过JFaceResources.getResources来获取ResourceManager，则不会默认享受Display的hook销毁机制，需要自己向Display注册），确保由被托管ImageDescriptor创建的残留在系统中的图片资源在Display release的时候会被彻底销毁。核心方法如下：

create(DeviceResourceDescriptor descriptor)  

//如果是首次注册，创建引用技数，allocate资源并对资源进行缓存

//如果是已经注册，增加引用技数，直接返回缓存的系统资源

       destroy(DeviceResourceDescriptor descriptor) //将

       //如果引用技术==1，通过调用deallocate彻底销毁资源

       //如果引用技术>1，削减引用计数（系统资源不会被销毁）

             

那就是说，如果一个ImageDescriptor被ResourceManager托管了，那由它创建的资源（注意：通过ImageDescriptor.createResource的方式）由两种销毁的途径：

1、            如果不通过JFaceResources.getResources的方式，单独使用ResourceManager，则只能利用ResourceManager的引用计数管理来销毁资源（引用计数为0时），通过显示调用ResourceManager.destroy来削减引用计数。

2、            如果通过JFaceResources.getResources来使用ResourceManager，则除了能够使用到引用计数管理资源，同时也默认使用了Display的hook销毁机制，JFace的ImageRegistry也很好的利用了这一点。

现在回头看一下ImageRegistry提供的核心操作，着重分析一下ImageRegistry在利用了ResourceManager对ImageDescriptor进行管理的基础上，做了那些补充：

put(String key, Image image)              //注册image

put(String key, ImageDescriptor descriptor) //注册descriptor

Image get(String key)                    //获取imge

ImageDescriptor getDescriptor(String key)   //获取descriptor

remove(String key)                      //取消注册

dipose()                               //销毁资源

通过对ImageRegistry简要的分析之后，我们的结论如下：

1、 如果以put(String key, ImageDescriptor descriptor)的方式注册，ImageRegistry直接讲descriptor委托给ResourceManager委托管理，自己并不承担管理任务。而且，ImageRegistry对这种方式注册的ImageDescriptor所创建的系统图片资源的销毁也委托给ResourceManager进行，并不是在以上自己的dispose方法中进行，而是在ResourceManager.dispose方法中进行。


2、 如果以put(String key, Image image)的方式注册，ImageRegistry做了部分的补充管理，其将image包装进自己的OriginalImageDescriptor（ImageRegistry的一个内部类，继承自ImageDescriptor，对图片资源本身增加引用计数）实现中，并对image本身进行了引用计数管理。同时，对这种方式注册的图片资源的销毁是ImageRegistry自己承担的，在自身的dispose方法中完成。（注意，在ImageRegistry的构造方法中，将ImageRegistry.dispose封装为一个runnable注册到了ResourceManage的dispose过程中，而ResourceManage.dispose已经在JFaceResources.getResources方法中被hook到了Display的资源销毁过程中）。

3、 通过1和2的结论，JFace ImageRegistry对系统资源的销毁已经做了两手准备，

其并不希望用户自己来销毁资源（无论是通过Image.dispose还是ImageDescriptor.destoryResource，或者ImageRegistry.dispose），当然，ImageRegistry允许通过remove接口来取消注册。

             

JFaceResources

＋提供hook机制

ImageRegistry

＋自己管理部分资源

ResourceManager

＋管理ImageDescriptor及其创建的资源
        
【ImageRegistry的适用场景和使用规则】

通过上面的实现原理分析，我们知道ImageRegistry并不欢迎用户来过多地参与图片资源的释放过程，所以ImageRegistry适用于如下场景：

1、 决定共享和高度复用的图片资源。这种资源一般是被使用的特别频繁，同时，不急于销毁，只要在Display release的时候销毁掉就可以了，所以既可以利用到图片资源本身缓存的优势（减少物理创建的次数），又可以利用其Display的hook销毁机制，确保会被销毁。

2、 用户可以直接使用ImageRegistry（不通过JFaceResources.getImageRegistry的方式使用），复用部分ImageRegistry的管理功能，开发自己的缓存策略，但是，要确保自己会在合适的地方调用ImageRegistry.dispose方法来销毁registry。Eclipse Workbench中的shared images机制就用了这一点。

ImageRegistry的使用规则如下：

1、 谁创建，谁负责。具体图片资源的创建是由ImageRegistry负责的，用户既然托管了，就不应该再干预资源的释放。而且，注册进ImageRegistry的资源是共享的，一个用户释放了，会影响到其他用户的使用。当然，对于比较熟悉JFace ImageRegistry原理的开发者，可以参与到引用计数的管理，通过这种方式，以安全的、不影响其他用户使用的方式来间接参与释放的过程。

2、 非共享图片资源请不要交由ImageRegistry托管。对于一个仅限于局部使用而且使用并不是十分频繁的图片资源，这样做不会带来什么好处，而且，尤其是对于不能参与到引用计数管理的初级用户，这样做反而会使得一个本可以马上释放的图片资源反而会一直占用，直到Display release的时候才销毁。

3、 要投入精力对ImageRegistry的key值进行管理，否则，会引起混乱。因为ImageRegistry本质上可以看作Eclipse平台中的一个全局对象，对其含有的key列表的管理是再所难免。
【Eclipse中插件share images机制】

       在Eclipse，一个插件可以暴露（expose）自己的图片资源，以便提供给需要的插件使用，我们就称它为插件之间的share images机制吧。上面提到过了，这其实是部分复用了JFace ImageRegistry的管理机制。

       如何共享（可以参照Workbench插件的share images实现）：

1、 按照默认约定，创建一个ISharedImages接口，提供有意义key值

2、 实现自己创建的ISharedImages接口，并结合ImageRegistry来管理图片资源；并提供显示的dipose公共接口，负责释放自己管理的图片资源

3、 在自己的插件中暴露ISharedImages

4、 在合适时机，调用ISharedImages.dispose来释放资源。这个时机一般选择在Plugin stop的时候比较合适，当然，也可以选择在其他时机。


如何使用：

1、 获取目标插件的ISharedImages实现，并通过ISharedImages提供的key值来获取特定的图片资源。以workbench插件share images为例：

PlatformUI.getWorkbench().getSharedImages().getImage(key)

2、暴露图片资源的插件负责图片资源的创建和销毁，其他插件不要参与销毁过程。换句话说，还是要遵守谁创建、谁负责的原则。以workbench插件share images为例：

在workbench close的时候，会间接调用ISharedImages.dispose()。
【Eclipse中使用图片资源的经验总结】

1、 坚持“谁创建，谁负责”的原则。分为如下：

a)         如果是用户自己创建的，请自己释放。例如通过覆写Component对于的dispose方法、通过覆写label provider对应的dispose方法等等，这对于一些适用于局部的图片资源较为适合；当然，也可以变态利用Display的hook释放机制（但是，一般对于长期使用的资源才会这样做！！！）。

b)        如果是通过JFaceResources.getImageRegistry的方式使用ImageRegistry时，请不要释放资源，让ImageRegistry自己解决。一般使用于比较频繁使用的全局共享图片资源，例如想保持风格统一的图片资源等。

c)        如果是使用了IShareImages的机制，请提供图片资源的插件自己负责释放。如何使用这种机制，最好参照eclipse中已有的实现，保持风格统一，“有样学样”吧。

2、 正确认识系统资源泄漏引起的crash问题的原因。导致原因有两种：

a)         首先，是没有释放，导致泄漏。请参照上面的“谁创建，谁负责”的原则。

b)        其次，是释放的过晚，导致积累过多。例如本来应该立即释放的资源，反而通过ImageRegistry进行了托管，同时有没有控制引用计数的管理，导致到了Display release的时候才释放资源。同样道理，本来不需要暴露给其他插件贡献的图片资源，反而暴露了，导致释放过完等。

3、 正确认识系统资源的创建和销毁所带来的时间消耗，这是从系统性能的角度考虑。例如，可以用ImageDescriptor.createResource的方式替换原始的new Image的方式，减少创建资源过于频繁和销毁资源过于频繁所带来的时间占用。对于需要长期使用的贡献资源，可以使用ImageRegistry的方式等等。

4、 对于特殊的场景，可以在参考以上原理（例如JFace中的图片管理的实现原理分析）的基础上自己实现图片资源的管理策略。这对团队开发产品的情况下尤其适用，一方面可以优化管理策略，使之更切近团队应用；再者，可以减少JFace ImageRegsitry使用的复杂度，并减少误用。例如，我们可以把插件间share images的机制看成是对JFace ImageRegsitry的灵活使用。

5、 无论使用那种管理策略（无论是来自eclipse还是其他），使用这前一定要仔细看API说明，并简要分析一下实现原理。对于做上规模的插件产品/应用来讲，毕竟对图片这种系统资源的管理太重要了！！！对于做较为简单的开发，基本上本着“谁创建、谁负责”的原则，用完之后在自己感觉合适的地方销毁掉就可以了，完全可以不去碰JFace中的ImageRegistry那套东东，引来不必要的负责度和复用，尤其是对于新手来说。