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

主要看你这个依赖是怎么定义了。

比如有这么一个登录的业务,首先验证帐号密码，在密码验证通过后，我需要更新一下群发消息通知一下别人。

这么一个需求，正常的编码也肯定会是

if(modelA.isLoginSuccess()){
  modelB  = serviceB.sendMessage()
}

这是一个业务，肯定需要开发人员进行编码，如果想单纯的依赖配置文件，我觉得反而对老系统有嵌入性了。
目前的想法，就是老的逻辑代码怎么写，加了异步加载后代码逻辑尽量都保持一致。

同样异步并行加载会存在一定技术上的难以规避的问题，比如如果直接使用modelA == null进行判断，因为异步返回的是一个假的，具体结果目前无法控制。

这个你可以看看主文中的代码例子。

因底层技术是采用字节码增强方式，包括service和model都会织入一定的代码，具体开发者是感觉不到的。就和正常的写代码是一样的方式，至于依赖关系的串行处理，也是植入代码内部的。

原先设计的理念就是尽量做到无嵌入，对开发透明。

理想的情况就是普通开发人员完成业务编码开发后，由项目的技术经理或者架构师，配置一份xml，决定哪些service的哪几个方法要进行异步并行加载。

这也是一种方法，何必不让开发者自己在applicationContext.xml中配置,决定哪些service以及方法需要异步并行加载呢？

支持的阿，你看下首页中关于 扩展一：AsyncLoadFactoryBean 描述这一块。

基于spring FactoryBean接口，配置方式就是纯spring ioc那一套，对哪个service的哪些方法进行异步加载。

根fork/join是两码事，fork/join主要用于处理一些主任务拆分成对等子任务。 而异步加载需要解决的是未知服务的并行加载，两个服务之间可能还存在数据上的依赖关系。

对于楼主说的这种类型的：
if(modelA.isOk()){//先依赖modelA的请求 
    modelB.getXXX() 
} 
确实可以异步加载，但更常见的是如下依赖类型的：
result = modelA.xxx();
modelB.xxxxx(result);
对于这种异步没用吧？

因目前技术实现的局限性，如果服务接口返回的是java的原始类型，暂不支持异步并行加载，final对象后续可考虑使用jdk proxy处理，目前代码没支持。

modelB.xxxx(result); 这里如果你的result是个对象类型时Integer,String等也可以支持。

呵呵，谢谢及时回复，那我就不明白了，既然modelB的加载（bbb方法的执行）依赖于ModelA执行的结果，A没有返回之前，B是加载不了的，实质上还是串行吧？
result = modelA.xxx();
modelB.bbb(result);

可能表述的依赖没讲清楚。

A服务依赖B，指A服务的请求发起或者请求参数，取决于B的返回的结果。

那假定这个B是一个pojo bean，那依赖结果的概念是指依赖bean具体的属性。

从技术实现上说，在调用serviceA获取结果的时，我会直接返回一个假的LazyLoad产生的mock对象。此时对应的属性值全为null，在你具体依赖到该modelA的属性数据时，就会有一个阻塞等待，转为串行的过程。

不知道说明白了没? 貌似很多人对这块有一定的理解偏差。

最后再看你的modeB.bbb(result)。 你这时的代码应该还不产生一种依赖关系，所以这里还是不会有阻塞，直接过去

tps 是什么东西