最近一位5年开发经验的群友与我聊天。

他说：最近慢慢的尝试去看spring的源码，学习spring，以前都只是会用就行了，但是越是到后面，发现只懂怎么用还不够，在面试的时候经常被问到一些开源框架的源码问题，即使在网上各种百度，当时回答出来也会是很皮毛，不痛不痒的解答。

如果你有认真好好的看《Java编程思想》，你应该能认识到，里面一句深刻的一句话，“编程语言是程序员的表达的方式，而架构是程序员对世界的认知”。 

读源码三问：“为什么要有这样的架构”，“他是什么样子的”，“他是怎么工作的”。

我们就拿 Spring IOC 举个例子。首先，来说说IoC容器。

相对于IoC而言，依赖注入(DI)更加准确地描述了IoC的设计理念。所谓依赖注入（Dependency Injection），即组件之间的依赖关系由容器在应用系统运行期来决定，也就是由容器动态地将某种依赖关系的目标对象实例注入到应用系统中的各个关联的组件之中。组件不做定位查询，只提供普通的Java方法让容器去决定依赖关系。

Spring框架使用这种方式。依赖注入是时下最流行的IoC实现方式，依赖注入分为接口注入（Interface Injection），Setter方法注入（Setter Injection）和构造器注入（Constructor Injection）三种方式。其中接口注入由于在灵活性和易用性比较差，现在从Spring4开始已被废弃。

用Java调用一点Spring试试：

ApplicationContext ct=new ClassPathXmlApplicationContext("applicationContext01.xml");ct.getBean("");

来看看啊，ClassPathXmlApplicationContext这是我们用来读文件的，可以读配置的文件的类不计其数，只取一个分析，足矣。

ClassPathXmlApplicationContext这个东西，我们可以追踪他的源头，AbstractXmlApplicationContext、AbstractRefreshableConfigApplicationContext、AbstractRefreshableApplicationContext、AbstractApplicationContext、DefaultResourceLoader、ResourceLoader，哇塞，怎么这么多类啊，要一个个读那不是死人了。

因此，我一般只读第一个和最后一个，可以知道它的根基。

public interface ResourceLoader {String CLASSPATH_URL_PREFIX = "classpath:";Resource getResource(String var1);ClassLoader getClassLoader();}

很明显啊，ResourceLoader 就是干了这么三件事嘛，定义了加载地址，第二，定义了资源加载的方法，第三，定义了类加载器。哦哦，原来如此，ResourceLoader就是IoC的灵魂嘛，负责就是找到资源和加载资源嘛。

我们来看下一个重要的类，getBean()接口提供类。

public interface BeanFactory { String FACTORY_BEAN_PREFIX = "&"; Object getBean(String var1) throws BeansException; <T> T getBean(String var1, Class<T> var2) throws BeansException; <T> T getBean(Class<T> var1) throws BeansException; Object getBean(String var1, Object... var2) throws BeansException; <T> T getBean(Class<T> var1, Object... var2) throws BeansException; boolean containsBean(String var1); boolean isSingleton(String var1) throws NoSuchBeanDefinitionException; boolean isPrototype(String var1) throws NoSuchBeanDefinitionException; boolean isTypeMatch(String var1, Class<?> var2) throws NoSuchBeanDefinitionException; Class<?> getType(String var1) throws NoSuchBeanDefinitionException; String[] getAliases(String var1);}

BeanFactory 很明显就是类的工厂。这下子清晰了吧，我们的Resource经过ResourceLoader的调和，用ClassLoader加载，最后变成了BeanFactory。这又是一个粗路线了。

我们想想资源是不是都需要定义和约束，于是有了BeanDefinition，我们需要封装，于是有了各种**wrapper。

我们再来想想细节吧，比如说循环注入问题，A引用B，B引用A，那么怎么吧，那不是循环插入到爆炸？那么Spring是怎么实现的。

我们越想越多，越来越有一种感觉就是，也许那么一刻，那些编程大师，那时候也和你一样这样低头沉思。保持这样的思考，画图，擦涂，重构，最后就是一个能和别人说的架构思想。

那么为什么要阅读源码呢？

随着自身工作年龄的增长或者职称的提高，遇到的问题越来越难，面对企业的高并发，高可用这些问题，已经不能用CRUD 来解决了。

回想以前的职业生涯，总结经验，然后把底层知识捡起来，去解决 CRUD 解决不了的难题，才懂得了代码的深层意义。

因此阅读源码框架成为每一位Java开发人员的必修课，而阅读源码则是学习源码底层的最好方式之一。

根据实践统计，工程师实际工作中，阅读代码的时间其实大大超过写代码的时间，这意味着阅读、总结能力，会直接影响我们的工作效率！

这东西有没有捷径呢，也许吧，我的心得是：无他，但手熟尔。