(业务层)异步并行加载技术分析和设计

现在已经基本透明了阿，开发在代码层面上不会感觉到任何AsyncLoad代码的存在。

半自动只是在我后端程序上的实现，会自动识别依赖并走串行处理。 对于开发来说，就和正常的写代码是一样的

最关键的问题是：
事实上如果不参看客户端代码，要如何自动识别依赖？
这一点还需要和timeout一起考虑。方法之间是否依赖可能会随着时间变化。

一种lazy的检查机制，你要依赖，必然会操作对应的model内的属性。这时机上可以植入相应的控制代码

不是很明白LZ说的自动识别依赖的方式。

如果业务开发人员写出的业务逻辑中调用比较多的服务接口，除非这些服务接口都按照某种统一的编码规范进行处理，不然很难从方法内部分析出依赖关系来。

但不知道通过分析堆栈轨迹或者字节码等方式能否得到相应的效果。

AllenZhang:
timeout这一块我觉得可以通过一个统一的事务管理器来控制，不用每个方法都关注

其实你可以思考下一般有依赖关系的代码会怎么写。
比如：

if(modelA.getXX()){
    modelB = serviceB.getModelB();
}

你可以在modelA.getXX()方法植入代码，进行相应的控制，说白了等待A的结果返回。:) 

LZ说的问题是实现业务的代码块，通常都是用串行的写法，即：
function test(){
   A.call(**);
   B.call(**);
}

如果这两个方法的调用没有依赖关系，那就可以采用异步并行处理的方法。缩短方法test()的执行所需要的时间，提升CPU的利用率。该方法所需要执行时间为：max(A.call(),B.call());

当然如果这两个方法有前后的依赖关系，那还得采用这种串行执行的方法。该方法所需要执行时间为：max(A.call()+B.call());

理解比较到位，:D

目前是否需要串行处理是透明处理，对具体写业务代码可以没有嵌入。 技术实现可以看下code，采用cglib字节码动态处理

示例代码： AsyncLoadFactoryBeanTest.java

LZ的想法很有创意，但是考虑到如果把这块功能抽象，采用类似拦截机制的方法在业务服务层做封装，可能需要考虑的问题会很多。 毕竟抽象层无法判断各个方法之间的依赖关系，即使采用显式的等待方式，可能也会增加程序的复杂度，或者实现封装代码块的复杂度。
   建议采用半自动化方式，由开发人员自己决定是否将方法投入到异步并行的容器中。就像spring中的ECcache、jbosscache配置使用一样。

其实我说的自动识别依赖关系不是指

if(modelA.getXX()){ 
    modelB = serviceB.getModelB(); 
}

这一个逻辑块，我关心的是如何能够动态识别得到if(?){}这个逻辑，这个逻辑才是服务接口间的依赖关系的表达，如果这个逻辑需要手写的话，那对开发人员的编码思维是强侵入的。

这个想法有挑战性。。。