背景
最近资讯asyncload使用的同学越来越多,会有些一些经常性的问题,这里我做一下整理和answer,同时介绍一下asyncload的UserGuide 和一些限制等。
关于asyncload,又名异步并行加载 ,可参见我之前的文章: (业务层)异步并行加载技术分析和设计
UserGuide篇
几个基本概念:
- 线程池 (定义异步处理的线程池模型,包括线程数,队列大小等)
- 匹配信息 (定义哪些方法需要实施,包括超时时间等)
- 匹配主体 (比如常见的service,dao等,需要进行异步并行加载处理的对象)
声明式: 常规配置(半侵入)
基本步骤:
1. 配置线程池
<bean id="asyncLoadExecutor" class="com.agapple.asyncload.AsyncLoadExecutor" init-method="initital" destroy-method="destory"> <property name="poolSize" value="10" /> <property name="acceptCount" value="20" /> <property name="mode" value="CALLSRUN" /> </bean>
- 关于poolSize/acceptCount的建议参数,请参考我的另一篇文章: ThreadPoolExecutor几点使用建议
- 关于mode参数,目前支持REJECT和CALLSRUN。
REJECT:当异步提交的任务数超过了acceptCount后,直接返回Reject异常
CALLSRUN:当异步提交的任务数超过了acceptCount后,由当前提交的线程执行runnable任务。此时的线程模型就变为了poolSize+1线程数,你的提交线程也就成为了其中的一个工作线程。建议使用该参数
2. 匹配信息配置
<bean id="asyncLoadConfig" class="com.agapple.asyncload.AsyncLoadConfig"> <property name="defaultTimeout" value="3000" /> <property name="needThreadLocalSupport" value="false" /> <property name="needBarrierSupport" value="false" /> <property name="matches"> <map> <entry key-ref="asyncLoadMethodMatch" value="2000" /> </map> </property> </bean>
- defaultTimeout:指异步提交任务后,等待返回结果的超时时间,可以有效保护系统的健壮性(当外部系统不可用时)。如果不想进行超时控制,可设置为0。默认值为0
- needThreadLocalSupport:指异步任务提交后,原先的正常业务处理线程A和异步任务的处理线程B,是否共享ThreadLocal变量,使用需慎用,一般不建议开启。默认值为false,不开启
- needBarrierSupport:指当原先一个业务处理线程,被拆分为N多个异步任务并行处理后,可以通过设置栅栏,在某一代码处要求所有的异步结果均返回后才进行下一步操作。默认值为false,不开启
- matches:匹配点定义,asyncload自带的匹配方式,如果使用spring拦截器处理可不配置该属性,使用spring pointcut定义匹配点。
<bean id="asyncLoadMethodMatch" class="com.agapple.asyncload.impl.AsyncLoadPerl5RegexpMethodMatcher" > <property name="patterns"> <list> <value>(.*)RemoteModel(.*)</value> </list> </property> <property name="excludedPatterns"> <list> <value>(.*)listRemoteModel(.*)</value> </list> </property> <property name="excludeOveride" value="false" /> </bean>
- patterns:代表满足该正则的匹配
- excludedPatterns:代表需要被排除的匹配
- excludeOveride:true/false
true: 优先执行excluded排除匹配
false:优先执行满足匹配,在满足匹配通过后,再执行排除匹配
3. 匹配主体配置
<bean id="asyncLoadTestFactoryBean" class="com.agapple.asyncload.impl.spring.AsyncLoadFactoryBean"> <property name="targetClass" value="com.agapple.asyncload.domain.AsyncLoadTestService" /><!-- 指定具体的代理目标class --> <property name="target"> <ref bean="asyncLoadTestService" /> </property> <property name="executor" ref="asyncLoadExecutor" /> <property name="config" ref="asyncLoadConfig" /> </bean>
- 类似于spring ProxyFactoryBean配置模式,对应的target即为你需要操作的服务对象。
- config即为匹配信息定义,步骤2中的定义
- executor即为线程池定义,步骤1中的定义
public class AsyncLoadFactoryBeanTest extends BaseAsyncLoadNoRunTest { @Resource(name = "asyncLoadTestFactoryBean") private AsyncLoadTestService asyncLoadTestFactoryBean; @Test public void testFactoryBean() { AsyncLoadTestModel model1 = asyncLoadTestFactoryBean.getRemoteModel("first", 1000); ............. } }注意:此时需要引用的bean name为步骤3中定义的主体配置中的名字。
声明式: 集成spring拦截器模式 (更少侵入)
步骤1: 配置线程池
见上一章节的步骤1定义
步骤2: 匹配信息配置
和上一章节的步骤2定义,基本类似。不过可以不需配置匹配点,可省略asyncLoadMethodMatch定义
步骤3:匹配主体配置
a. 定义拦截器
<bean id="asyncLoadInterceptor" class="com.agapple.asyncload.impl.spring.AsyncLoadInterceptor" > <property name="asyncLoadTemplate" ref="asyncLoadTemplate" /> </bean>
- 注意这里依赖了一个asyncLoadTemplate配置,后面再介绍下对应的配置。
定义一个pointcut
<bean id="asyncLoadPointcut" class="org.springframework.aop.support. Perl5RegexpMethodPointcut"> <property name="pattern"> <value>(.*)RemoteModel(.*)</value> </property> <property name="ExcludedPattern"> <value>(.*)listRemoteModel(.*)</value> </property> </bean>
<bean id="asyncloadAdvisor" class="org.springframework.aop.support.DefaultPointcutAdvisor"> <property name="advice" ref="asyncLoadInterceptor"></property> <property name="pointcut" ref="asyncLoadPointcut"></property> </bean>
<bean id="asyncLoadTestProxy" class="org.springframework.aop.framework.ProxyFactoryBean"> <property name="proxyTargetClass" value="true" /> <property name="target" ref="asyncLoadTestService" /> <property name="interceptorNames"> <list> <value>asyncLoadInterceptor</value> </list> </property> </bean>
这样就完成了配置,是不是觉得比较easy.
步骤4:使用 (AsyncLoadSpringInteceptorTest)
public class AsyncLoadSpringInteceptorTest extends BaseAsyncLoadNoRunTest { @Resource(name = "asyncLoadTestServiceForInteceptor") private AsyncLoadTestService asyncLoadTestServiceForInteceptor; @Test public void testSpringInteceptor() { AsyncLoadTestModel model1 = asyncLoadTestServiceForInteceptor.getRemoteModel("first", 1000); AsyncLoadTestModel model2 = asyncLoadTestServiceForInteceptor.getRemoteModel("two", 1000); long start = 0, end = 0; start = System.currentTimeMillis(); System.out.println(model1.getDetail()); end = System.currentTimeMillis(); Assert.assertTrue((end - start) > 500l); // 第一次会阻塞, 响应时间会在1000ms左右 start = System.currentTimeMillis(); System.out.println(model2.getDetail()); end = System.currentTimeMillis(); Assert.assertTrue((end - start) < 500l); // 第二次不会阻塞,第一个已经阻塞了1000ms } }
可以直接操作原先的主体bean
--------------------------------------------------------------------------------分割线--------------------------------------------------------------------------------------------------------------
如果是兼容老系统,减少配置变更,可以考虑使用spring auto-proxy机制,对原先的配置侵入几乎为0
spring: BeanNameAutoProxyCreator auto-proxy,直接针对现有的bean name实施拦截器切入
<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"> <property name="optimize" value="false"/> <property name="proxyTargetClass" value="false" /> <property name="beanNames"> <list> <value>asyncLoadTestServiceForInteceptor</value> </list> </property> <property name="interceptorNames"> <list> <value>asyncLoadInterceptor</value> </list> </property> </bean>
asyncload : CompositeAutoProxyCreator ,使用: AsyncLoadSpringCompsiteTest
<bean class="com.agapple.asyncload.impl.spring.CompositeAutoProxyCreator"> <property name="optimize" value="false"/> <property name="proxyTargetClass" value="false" /> <property name="beanNames"> <list> <value>asyncLoadTestServiceForInteceptor</value> </list> </property> <property name="interceptorNames"> <list> <value>asyncLoadInterceptor</value> </list> </property> </bean>
相比于BeanNameAutoProxyCreator,CompositeAutoProxyCreator会有一种融合机制,假如发现需要操作的bean已经进行了spring aop代理配置后,直接将当前的interceptor加入到原先aop配置定义中,而不会是两次代理封装)
两次代理封装问题:
- 第一次封装为cglib代理后,生成的对象为final类,无法再次生成cglib代理类。如果无接口,无法再次生成jdk代理
(编程式)模板模式
模板模式: AsyncLoadTemplate
配置:
<bean id="asyncLoadTemplate" class="com.agapple.asyncload.impl.template.AsyncLoadTemplate" > <property name="executor" ref="asyncLoadExecutor" /> <property name="config" ref="asyncLoadConfig" /> </bean>
- 需要依赖线程池定义 和 匹配信息定义
public class AsyncLoadTemplateTest extends BaseAsyncLoadNoRunTest { @Resource(name = "asyncLoadTemplate") private AsyncLoadTemplate asyncLoadTemplate; @Resource(name = "asyncLoadTestService") private AsyncLoadTestService asyncLoadTestService; @Test public void testTemplate() { AsyncLoadTestModel model2 = asyncLoadTemplate.execute(new AsyncLoadCallback<AsyncLoadTestModel>() { public AsyncLoadTestModel doAsyncLoad() { // 总共sleep 2000ms return asyncLoadTestService.getRemoteModel("ljhtest", 1000); } }); } }
- 接受AsyncLoadCallback进行异步并行业务处理单元封装
使用模板模式的好处: (自由定义异步并行处理单元)
- 比如针对服务B依赖服务A,两者依赖的间隔时间很多,当将A和B的调用各自做异步并行加载,会发现A的调用几乎都是阻塞式。此时可以选择将A和B的一个完整处理,做为一个异步并行处理的单元。
- 比如一个方法调用中,可以考虑将部分代码进行异步调用,而不是以方法为一个单元。
(编程式)非spring容器
public class AsyncLoadProxyTest extends BaseAsyncLoadNoRunTest { @Test public void testProxy() { AsyncLoadTestService asyncLoadTestService = xxxxx; //你原先的业务处理主体 // 初始化config AsyncLoadConfig config = new AsyncLoadConfig(3 * 1000l); // 初始化executor AsyncLoadExecutor executor = new AsyncLoadExecutor(10, 100); executor.initital(); // 初始化proxy AsyncLoadEnhanceProxy<AsyncLoadTestService> proxy = new AsyncLoadEnhanceProxy<AsyncLoadTestService>(); proxy.setService(asyncLoadTestService); //传递你原先的业务对象 proxy.setConfig(config); proxy.setExecutor(executor); AsyncLoadTestService service = proxy.getProxy(); //获取到异步并行处理包装过的服务对象 // 执行测试 AsyncLoadTestModel model1 = service.getRemoteModel("first", 1000); // 进行业务请求 } }
DevGuide 篇
1. asyncload是否存在一些使用限制?
ans : 存在一定的使用限制和建议
使用限制:
- 不支持 == null的判断 (原因: asyncload因为需要做异步处理,所以在执行方法调用时,比如xxxService.getRemote()。会预先生成一个假的返回对象,永远不会为null, 所以==null一定返回为false)
规避: 可以使用AsyncLoadUtils.isNull(xxxModel)进行判断,注意调用此方法,会阻塞直到原先的调用结果返回,然后再依据返回结果进行==null判断 - 不支持以下几种的方法调用,主要是针对返回结果类型:
a. void, 没有返回对象。
b. final类,比如java.lang.String
c. java.lang.Object,因为asyncload分析是基于当前的class,不能基于运行时对象进行处理。所以针对方法定义中返回为java.lang.Object的不支持
d. 原生类型, 比如int,long等
e. array类型,比如int[],long[]等
f. 非public的类型,比如在一些类的返回结果,返回了一个内部protected类 - threadlocal使用限制 (原先:引入asyncload后,原先在一个线程中处理的业务会分散到多个线程中,所以ThreadLocal默认无法进行共享处理,虽然asyncload可以有技术做到共享ThreadLocal,但这样会打破原先ThreadLocal的语义,导致出现线程安全问题。严重慎用)
规避:使用模板模式控制拦截器粒度,尽量将ThreadLocal的操作放在一个异步并行处理单元,或者不进行异步处理。
使用建议:
- 应用在I/O只读查询操作上,比如查询数据库,调用远程服务接口,调用cache等。
- 将请求发起放在前面调用,数据结果处理统一在最后处理。尽量让请求可以走到并行处理
- 使用spring无嵌入配置(composite配置)
2. asyncload异步并行处理后,如何确保返回结果?提交给ThreadPoolExectuor后的future是如何存储的?
比如有个ProductService中,有个方法ProductModel product.getProductById(Long productId)
ans : asyncload会在两个层面进行扩展处理(字节码或者拦截器)
- 服务主体层(ProductService),asyncload会通过常规配置(字节码处理)或者拦截器配置,会改变原先对于getProductById()的方法调用逻辑,这里就会提交到一个线程池中进行处理。
return asyncLoadTemplate.execute(new AsyncLoadCallback() { public Object doAsyncLoad() { try { return temp.proceed(); } catch (Throwable e) { throw new AsyncLoadException("AsyncLoadInterceptor invoke error!", e); } } }, invocation.getMethod().getReturnType()); // 这里指定了返回目标class
- 服务返回对象(ProductModel):asyncload提交任务到线程池之后,会根据原先method.getReturnType()获取到返回结果的类型定义,通过字节码处理技术生成了一个原先retrunType类型的子类,同时覆盖了原先ProductModel中的所有方法,比如getId()方法就会变为:
public ProductModelSub extends ProductModel { public Future future; //持有线程池返回对象 public Object loadObject() throws Exception { return loadFuture(); } private Object loadFuture() throws AsyncLoadException { try { // 使用cglib lazyLoader,避免每次调用future if (timeout <= 0) {// <=0处理,不进行超时控制 return future.get(); } else { return future.get(timeout, TimeUnit.MILLISECONDS); } } catch (TimeoutException e) { future.cancel(true); throw new AsyncLoadException(e); } catch (InterruptedException e) { throw new AsyncLoadException(e); } catch (Exception e) { throw new AsyncLoadException(e); } } public Long getId(){ ProductModel model = loadObject(); //先阻塞等待future返回 return model.getId(); } }
调用productModel.getId()方法就会先调用loadFuture(),阻塞等待future的返回,然后再委托给future的返回对象调用getId方法进行返回
3. asyncload的服务依赖关系链的处理?
ans :
首先依赖关系的定义:如果服务B依赖了服务A的返回结果。(比如这里是ProductModel.getId()的返回结果,将做为服务B ProductDetailService.getProudctDetailByProductId(Long productId)),进行服务B的返回调用参数)
出现依赖关系后的处理:其实很简单,当B需要ProductModel.getId()的结果,进行构造自己的参数时,此时服务A的调用就会。也就是转变为了A,B是一个串行调用。
4. asyncload的线程池配置是否有讲究 ?
ans: poolSize不宜开的过大,一般建议为20~30,acceptCount建议为poolSize的两倍,model建议为CALLSRUN。
关于poolSize/acceptCount的建议参数,请参考我的另一篇文章: ThreadPoolExecutor几点使用建议
4. asyncload是否可以提升性能? 比如tps ,响应时间?
ans :
- 针对响应时间,为你最长依赖关系链的时间之后。所以只要你配置后的依赖关系链有一处做了并行,就可以得到提升。这里需要注意线程池的设置,避免出现大量的异步任务进行等待,导致单个任务的处理时间过长。
- 针对tps,计算公式 tps = 1000 / (每个request的响应时间),只要响应时间减少了,可支持的tps就会上升。注意如果你当前统计的访问tps只有100个,没有出现竞争资源瓶颈,使用asyncload后,当前的tps是不会增加,说白了你每秒就100个request。 (可支持tps会增加,如果当前tps已经存在竞争瓶颈,就会有所增加)
可以分享一下我当时一个实施场景的数据:(2o并发的持续高压)
对比项 | 主干代码 | 并行加载实施代码 | 提升幅度 | 提升百分比 |
响应时间 | 347ms | 281ms | 66ms | 19% |
tps | 60.7 | 70.9 | 10.2 | 16.8% |
cpu使用率 | user:44.97% sys:4.67% |
user:53.12% sys:5.87% |
user:8.15 sys:1.2 |
user:18.1% sys:25.7% |
load | 9.39 | 6.21 | 3.18 | 51.2% |
最后
目前asyncload的实施场景已经有好多个,包括阿里巴巴,淘宝,良无限等。至于提升多少性能要结合具体的业务,也就是说你的可提升空间有多少。当然异步并行后,会适当的增加系统资源的消耗。
相关推荐
Asyncload是一款异步并行加载工具(依赖字节码技术)。背景前段时间在做应用的性能优化时,分析了下整体请求,profile看到90%的时间更多的是一些外部服务的I/O等待,cpu利用率其实不高,在10%以 下。 单次请求的响应...
内容概要:本文详细介绍了如何利用Matlab构建、优化和应用决策分类树。首先,讲解了数据准备阶段,将数据与程序分离,确保灵活性。接着,通过具体实例展示了如何使用Matlab内置函数如fitctree快速构建决策树模型,并通过可视化工具直观呈现决策树结构。针对可能出现的过拟合问题,提出了基于成本复杂度的剪枝方法,以提高模型的泛化能力。此外,还分享了一些实用技巧,如处理连续特征、保存模型、并行计算等,帮助用户更好地理解和应用决策树。 适合人群:具有一定编程基础的数据分析师、机器学习爱好者及科研工作者。 使用场景及目标:适用于需要进行数据分类任务的场景,特别是当需要解释性强的模型时。主要目标是教会读者如何在Matlab环境中高效地构建和优化决策分类树,从而应用于实际项目中。 其他说明:文中不仅提供了完整的代码示例,还强调了代码模块化的重要性,便于后续维护和扩展。同时,对于初学者来说,建议从简单的鸢尾花数据集开始练习,逐步掌握决策树的各项技能。
《营销调研》第7章-探索性调研数据采集.pptx
Assignment1_search_final(1).ipynb
美团优惠券小程序带举牌小人带菜谱+流量主模式,挺多外卖小程序的,但是都没有搭建教程 搭建: 1、下载源码,去微信公众平台注册自己的账号 2、解压到桌面 3、打开微信开发者工具添加小程序-把解压的源码添加进去-appid改成自己小程序的 4、在pages/index/index.js文件搜流量主广告改成自己的广告ID 5、到微信公众平台登陆自己的小程序-开发管理-开发设置-服务器域名修改成
《计算机录入技术》第十八章-常用外文输入法.pptx
基于Andorid的跨屏拖动应用设计实现源码,主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者,也可作为课程设计、期末大作业。
《网站建设与维护》项目4-在线购物商城用户管理功能.pptx
区块链_房屋转租系统_去中心化存储_数据防篡改_智能合约_S_1744435730
《计算机应用基础实训指导》实训五-Word-2010的文字编辑操作.pptx
《移动通信(第4版)》第5章-组网技术.ppt
ABB机器人基础.pdf
《综合布线施工技术》第9章-综合布线实训指导.ppt
很不错的一套站群系统源码,后台配置采集节点,输入目标站地址即可全自动智能转换自动全站采集!支持 https、支持 POST 获取、支持搜索、支持 cookie、支持代理、支持破解防盗链、支持破解防采集 全自动分析,内外链接自动转换、图片地址、css、js,自动分析 CSS 内的图片使得页面风格不丢失: 广告标签,方便在规则里直接替换广告代码 支持自定义标签,标签可自定义内容、自由截取、内容正则截取。可以放在模板里,也可以在规则里替换 支持自定义模板,可使用标签 diy 个性模板,真正做到内容上移花接木 调试模式,可观察采集性能,便于发现和解决各种错误 多条采集规则一键切换,支持导入导出 内置强大替换和过滤功能,标签过滤、站内外过滤、字符串替换、等等 IP 屏蔽功能,屏蔽想要屏蔽 IP 地址让它无法访问 ****高级功能*****· url 过滤功能,可过滤屏蔽不采集指定链接· 伪原创,近义词替换有利于 seo· 伪静态,url 伪静态化,有利于 seo· 自动缓存自动更新,可设置缓存时间达到自动更新,css 缓存· 支持演示有阿三源码简繁体互转· 代理 IP、伪造 IP、随机 IP、伪造 user-agent、伪造 referer 来路、自定义 cookie,以便应对防采集措施· url 地址加密转换,个性化 url,让你的 url 地址与众不同· 关键词内链功能· 还有更多功能等你发现…… 程序使用非常简单,仅需在后台输入一个域名即可建站,不限子域名,站群利器,无授权,无绑定限制,使用后台功能可对页面进行自定义修改,在程序后台开启生 成功能,只要访问页面就会生成一个本地文件。当用户再次访问的时候就直接访问网站本地的页面,所以目标站点无法访问了也没关系,我们的站点依然可以访问, 支持伪静态、伪原创、生成静态文件、自定义替换、广告管理、友情链接管理、自动下载 CSS 内的图。
【自然语言处理】文本分类方法综述:从基础模型到深度学习的情感分析系统设计
基于Andorid的下拉浏览应用设计实现源码,主要针对计算机相关专业的正在做毕设的学生和需要项目实战练习的学习者,也可作为课程设计、期末大作业。
内容概要:本文详细介绍了一个原创的P2插电式混合动力系统Simulink模型,该模型基于逻辑门限值控制策略,涵盖了多个关键模块如工况输入、驾驶员模型、发动机模型、电机模型、制动能量回收模型、转矩分配模型、运行模式切换模型、档位切换模型以及纵向动力学模型。模型支持多种标准工况(WLTC、UDDS、EUDC、NEDC)和自定义工况,并展示了丰富的仿真结果,包括发动机和电机转矩变化、工作模式切换、档位变化、电池SOC变化、燃油消耗量、速度跟随和最大爬坡度等。此外,文章还深入探讨了逻辑门限值控制策略的具体实现及其效果,提供了详细的代码示例和技术细节。 适合人群:汽车工程专业学生、研究人员、混动汽车开发者及爱好者。 使用场景及目标:①用于教学和科研,帮助理解和掌握P2混动系统的原理和控制策略;②作为开发工具,辅助设计和优化混动汽车控制系统;③提供仿真平台,评估不同工况下的混动系统性能。 其他说明:文中不仅介绍了模型的整体架构和各模块的功能,还分享了许多实用的调试技巧和优化方法,使读者能够更好地理解和应用该模型。
内容概要:本文详细介绍了基于ADMM(交替方向乘子法)算法在电力系统分布式调度中的应用,特别是并行(Jacobi)和串行(Gauss-Seidel)两种不同更新模式的实现。文中通过MATLAB代码展示了这两种模式的具体实现方法,并比较了它们的优劣。并行模式适用于多核计算环境,能够充分利用硬件资源,尽管迭代次数较多,但总体计算时间较短;串行模式则由于“接力式”更新机制,通常收敛更快,但在计算资源有限的情况下可能会形成瓶颈。此外,文章还讨论了惩罚系数rho的自适应调整策略以及在电-气耦合系统优化中的应用实例。 适合人群:从事电力系统优化、分布式计算研究的专业人士,尤其是有一定MATLAB编程基础的研究人员和技术人员。 使用场景及目标:①理解和实现ADMM算法在电力系统分布式调度中的应用;②评估并行和串行模式在不同应用场景下的性能表现;③掌握惩罚系数rho的自适应调整技巧,提高算法收敛速度和稳定性。 其他说明:文章提供了详细的MATLAB代码示例,帮助读者更好地理解和实践ADMM算法。同时,强调了在实际工程应用中需要注意的关键技术和优化策略。
内容概要:本文深入研究了交错并联Buck变换器的工作原理、性能优势及其具体实现。文章首先介绍了交错并联Buck变换器相较于传统Buck变换器的优势,包括减小输出电流和电压纹波、降低开关管和二极管的电流应力、减小输出滤波电容容量等。接着,文章详细展示了如何通过MATLAB/Simulink建立该变换器的仿真模型,包括参数设置、电路元件添加、PWM信号生成及连接、电压电流测量模块的添加等。此外,还探讨了PID控制器的设计与实现,通过理论分析和仿真验证了其有效性。最后,文章通过多个仿真实验验证了交错并联Buck变换器在纹波性能、器件应力等方面的优势,并分析了不同控制策略的效果,如P、PI、PID控制等。 适合人群:具备一定电力电子基础,对DC-DC变换器特别是交错并联Buck变换器感兴趣的工程师和技术人员。 使用场景及目标:①理解交错并联Buck变换器的工作原理及其相对于传统Buck变换器的优势;②掌握使用MATLAB/Simulink搭建交错并联Buck变换器仿真模型的方法;③学习PID控制器的设计与实现,了解其在电源系统中的应用;④通过仿真实验验证交错并联Buck变换器的性能,评估不同控制策略的效果。 其他说明:本文不仅提供了详细的理论分析,还给出了大量可运行的MATLAB代码,帮助读者更好地理解和实践交错并联Buck变换器的设计与实现。同时,通过对不同控制策略的对比分析,为实际工程应用提供了有价值的参考。
《综合布线施工技术》第8章-综合布线工程案例.ppt