ActiveMQ 源码学习 1:从源码中找寻设计模式的踪影_JAVA_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > JAVA > ActiveMQ 源码学习 1:从源码中找寻设计模式的踪影

ActiveMQ 源码学习 1:从源码中找寻设计模式的踪影

 2013/8/18 21:28:45  wxl24life  程序员俱乐部  我要评论(0)
  • 摘要:今天主要分析两个类的实现。首先看一下org.apache.activemq.broker.BrokerFactory类。从类的命名上看似乎使用了GoF设计模式中的抽象工厂模式。我们通过源码来分析一下是否真的应用了这种模式。publicfinalclassBrokerFactory{//...publicstaticBrokerServicecreateBroker(URIbrokerURI,booleanstartBroker)throwsException{if(brokerURI
  • 标签:学习 源码 模式 设计 设计模式

今天主要分析两个类的实现。

首先看一下 org.apache.activemq.broker.BrokerFactory 类。从类的命名上看似乎使用了?GoF?设计模式中的抽象工厂模式。我们通过源码来分析一下是否真的应用了这种模式。

?

?

class="java" name="code">public final class BrokerFactory {

    // ...

    public static BrokerService createBroker(URI brokerURI, boolean startBroker) throws Exception {
        if (brokerURI.getScheme() == null) {
            throw new IllegalArgumentException("Invalid broker URI, no scheme specified: " + brokerURI);
        }
        BrokerFactoryHandler handler = createBrokerFactoryHandler(brokerURI.getScheme());
        BrokerService broker = handler.createBroker(brokerURI);
        if (startBroker) {
            broker.start();
        }
        return broker;
    }
}

?

BrokerFactory 的主要功能是根据 URI(指向某个配置文件)创建 BrokerService 实例,URI 的语法决定了所创建的 broker service 的具体类型,如 createBroker 方法实现中所示。

?

来回顾一下抽象工厂模式的结构。

抽象工厂模式包含两种类的继承层次关系。抽象工厂(abstract factory)和具体工厂(concret factory)组成的工厂类继承关系,以及由抽象产品(abstract product)和具体产品(concret product)组成的产品类继承关系。

?

在 BrokerFactory 中,由于其主要功能是要创建 broker service 实例,因而套用在抽象工厂模式下,BrokerService 就充当了模式中的抽象产品类,而 BrokerService 的子类,如 XBeanBrokerService 等,则扮演了具体产品的角色。

?

有了产品类继承关系,接下来的问题是,BrokerFactory 是否是作为抽象工厂模式中的抽象工厂类存在的呢?

?

继续看 createBroker 方法的实现,会发现 BrokerFactory 将 broker service 的创建转移给了某个 BrokerFactoryHandler 的实例,该实例是通过 createBrokerFactoryHandler 方法得到的。

?

private static final FactoryFinder BROKER_FACTORY_HANDLER_FINDER = new FactoryFinder("META-INF/services/org/apache/activemq/broker/");

    public static BrokerFactoryHandler createBrokerFactoryHandler(String type) throws IOException {
        try {
            return (BrokerFactoryHandler) BROKER_FACTORY_HANDLER_FINDER.newInstance(type);
        } catch (Throwable e) {
            throw IOExceptionSupport.create("Could not load " + type + " factory:" + e, e);
        }
}

?

createBrokerFactoryHandler 方法根据参数的值创建不同种类的 BrokerFactoryHandler 实例。而 BrokerFactoryHandler 被定义为接口类,它只提供了一个接口方法 createBroker,其作用也是用于创建 broker service 实例,因而它才是真正的 broker service 的抽象工厂。继续分析发现,BrokerFactoryHandler 的实现类中包含 XBeanBrokerFactoryHandler,因而可以肯定 BrokerFactoryHandler 及其实现类构成了抽象工厂模式中的工厂类继承层次关系。

?

接下来,我们来看另一个更有意思的工具类?FactoryFinder?的实现。在这个类的实现中会看到另一种设计模式的应用,以及有关多线程的考虑。

?

?

public class FactoryFinder {
    /**
     * The strategy that the FactoryFinder uses to find load and instantiate Objects
     * ...
     */
    public interface ObjectFactory {
        /**
         * @param path the full service path 
         * @return
         */
        public Object create(String path) throws IllegalAccessException, InstantiationException, IOException, ClassNotFoundException;

    }

    /**
     * The default implementation of Object factory which works well in standalone applications.
     */
    protected static class StandaloneObjectFactory implements ObjectFactory {
    // ...
    }

    // ================================================================
    // Class methods and properties
    // ================================================================

    private static ObjectFactory objectFactory = new StandaloneObjectFactory();

    public static ObjectFactory getObjectFactory() {
        return objectFactory;
    }

    public static void setObjectFactory(ObjectFactory objectFactory) {
        FactoryFinder.objectFactory = objectFactory;
    }

    // ================================================================
    // Instance methods and properties
    // ================================================================
    private final String path;

    public FactoryFinder(String path) {
        this.path = path;
    }

    public Object newInstance(String key) throws IllegalAccessException, InstantiationException, IOException, ClassNotFoundException {
        return objectFactory.create(path+key);
   }
}

?

代码注释中已经给出了这种设计模式:策略模式?Strategy。FactoryFinder 类的 ObjectFactory 实例属性定义了用于加载和实例化对象的策略,并以内部类的形式定义了缺省的策略实现 — StandaloneObjectFactory。如果想修改策略,可以自定义实现 ObjectFactory 接口的类,并通过 setObjectFactory 方法将策略应用与 FactoryFinder。

?

我们来看 StandaloneObjectFactory 的实现,只看 create 方法:

?

protected static class StandaloneObjectFactory implements ObjectFactory {
        final ConcurrentHashMap<String, Class> classMap = new ConcurrentHashMap<String, Class>();

        @Override
        public Object create(final String path) throws InstantiationException, IllegalAccessException, ClassNotFoundException, IOException {
            Class clazz = classMap.get(path);
            if (clazz == null) {
                clazz = loadClass(loadProperties(path));
                classMap.put(path, clazz);
            }
            return clazz.newInstance();
        }

        // loadClass(Properties properties) 
        // Properties loadProperties(String uri)    
}

?

这里用到了 ConcurrentHashMap,它是 Java 5 提供的一个线程安全的 HashMap 实现。

?

ConcurrentHashMap 还能允许多个线程对 Map 的操作(读、写)以无阻塞的方式进行。在 Java 5 之前,还有一种线程安全的 HashMap 实现,Collections.synchronizedMap(Map),它的实现中用到了 bloking Map,意即当多个线程同时访问该 Map 时,只有一个线程处在活跃状态,其他线程会被阻塞,因而可能会影响性能。关于这两种实现的对比讨论,请参考?SO 上的这个问答。

?

我这里关心的是另一个细节。create 方法应该是希望实现相同的 path 返回同一个 Class 的。

?

Class clazz = classMap.get(path);
    if (clazz == null) {
        clazz = loadClass(loadProperties(path));
        classMap.put(path, clazz);
    }
    return clazz.newInstance();

?

刚才说道,ConcurrentHashMap 是线程安全的,但是上面这一小段代码却有可能存在一致性的问题,即它并不符合线程安全的条件。

  • 假设 A 和 B 两个线程同时执行,在某个时刻 A 和 B 都从 classMap 中取到同一个 path 对应的 clazz,且均检查发现 clazz 是 null。之后 A 和 B 分别根据 path 计算自己的 clazz,并先后执行 put 语句。如果 A 和 B 计算得到的 clazz 不同,先后执行 put 就会出现后面覆盖前面的情况。因而,最终 classMap 中存放的值将取决与时序关系。

当然,考虑到 StandaloneObjectFactory 中实际的应用场景,同一个 path 一定会返回相同的 clazz,因而上面这段代码不会导致不一致。

?

如果不允许覆盖,更好的实现我认为是这样的:

?

Class clazz = classMap.get(path);
    if (clazz == null) {
        clazz = loadClass(loadProperties(path));
        Class ret = classMap.putIfAbsent(path, clazz);
        if (ret != null)
            clazz = ret;
    }
    return clazz.newInstance();

?

用 ConcurrentHashMap 的 putIfAbsent 往 Map 中放 Key-Value,并根据返回值判断原来的 Map 中是否已经存在该 Key-Value 对。

?

完。

?

** 这篇文章属于原创,最早在7月28号发布在?Wordpress,转到这里算是对今天阅读的一篇文章(Why I Love Reading Other People’s Code And You Should Too?)的响应。很长一段时间以来,我都不满意 iteye 的排版,加之这篇文字最早是使用 markdown 语法写的,而我发现 wordpress 对 markdown 文件转成的 html 的支持很赞(几乎可以直接复制粘贴,效果见前面的 wordpress 链接),所以并没有发到这里。直到最近逐渐习惯了 iteye 的排版之后,决定把之前在 wordpress 上的文章贴过来,便于一处维护,也便于与大家分享和讨论问题:-)
发表评论
用户名: 匿名