本来是在debug dubbo的reference bean的init()过程，因为ReferenceBean是继承了Spring FactoryBean接口的，
所以初始化入口自然就是FactoryBean定义的函数，getObject()。在该方法内，只显示调用了ReferenceConfig.get()。
内容如下：
public synchronized
可以看到，核心的初始化代码就在init()中。这里，会首先判断factoryBean 要创建的bean实例ref是否已经初始化，若未初始化，才会进行Init()调用。
所以，我断点自然就打在ReferenceBean.getObject()上。
启动spring。
反复多次，我发现，只要我在ReferenceBean.getObject()或者ReferenceConfig.get()上加上断点，ref实例就会莫名其妙地已经被初始化过，proxy$xxxx。
这就奇怪了。
这个ReferenceBean的整个的入口函数，getObject()的触发，是在我的控制下的啊，即：
springContext.getBean("referenceBeanId");
那我就在想，是不是spring container的初始化有异步的部分呢？所以我就直接把断点加载init()方法上。
然后我返回调试后发现，如果我只将断点加在Init()，而ReferenceBean.getObject()与ReferenceConfig.get()不加断点的话，init()方法里是正常进入，且进入的代码initialized也是false的
private void
}
就是init（）开头4行代码处。
后来我就想，是不是哪里给反射注入了呢？当然，我也没啥发现，我就直接百度了。结果果不其然。
在网上发现了一篇同样问的文章。那个人在源码里加了一段注释，如下
图片已损坏
图片已损坏
可以看到，AbstractConfig.toString()方法竟然反射调用了ReferenceConfig.init()方法。。。
AbstractConfig.toString()的代码如下：
可以看到，这个if里是对所有getter通过的，通过后，又再接下来的红框处调用了我擦，也就是说，ReferenceBean.getObject()给调用了，进而也就init()给调用了。
后来，原文作者又做了这样一个测试，得出了最终结果
图片已损坏
结果就是：
IDEA这类编辑器的debug功能为了在断点处能够显示类实例的相关信息，就会反射调用相关类实例的toString()方法！！！！
思考：
DUBBO为什么要在AbstractConfig.toString()的反射调用init()呢？真尼玛奇怪。。。。
答案：
dubbo的AbstractConfig的toString方法反射调用只是为了输出时能够更全面一点。但是因为AbstractConfig的子类
ReferenceBean实现了FactoryBean接口，这个接口是Spring用来获取Bean实例的工厂bean，生成bean的方法就叫getObject，正好符合了toString里面逻辑，而getObject里是要初始化bean的。所以，就这么巧地对应上了