- 浏览: 4412618 次
- 性别:
- 来自: 北京
-
文章分类
- 全部博客 (163)
- 职场 && 心情 (22)
- Java/Basic (17)
- Java/Compression (7)
- Java/Security (20)
- Java/Maven (3)
- Java/Cache (11)
- Eclipse (4)
- Spring (19)
- ORM/Hibernate (2)
- ORM/iBatis (3)
- DB/NoSQL (11)
- DB/MySQL (7)
- DB/MS SQL Server (4)
- OS/Linux (11)
- OS/Mac (7)
- C/C++ (4)
- Server Architecture/Basic (13)
- Server Architecture/Distributed (17)
- Moblie/Andriod (2)
- WebService (3)
- Objective-C (1)
- Html (1)
- 设计模式 (1)
- Scala (0)
- Kafka (1)
最新评论
-
w47_csdn:
证书安装:在"浏览"选项中选择" ...
Java加密技术(九)——初探SSL -
w47_csdn:
spiritfrog 写道你好,我按照你的步骤,tomcat中 ...
Java加密技术(九)——初探SSL -
liuyachao111:
11楼说的对 用@ControllerAdvicepublic ...
Spring 注解学习手札(八)补遗——@ExceptionHandler -
irayslu:
作者你好, 我把你的源码放在jdk6, jdk7 中运行正常, ...
Java加密技术(五)——非对称加密算法的由来DH -
夏季浅忆-卖小子:
为什么不能解压rar格式的压缩包呢
Java压缩技术(三) ZIP解压缩——Java原生实现
最近接手服务器总被人质疑效率问题,说到底是质疑Spring HttpInvoke的效率问题。好在经过同事们的努力,找到了问题的根源,最终解决了这个问题。
我也顺道整理一下Spring HttpInvoke——那曾经最为熟悉的东西。
Spring HttpInvoke,一种较为常用的、基于Spring架构的服务器之间的远程调用实现,可以说是轻量级的RMI。
最初,我们使用Spring HttpInvoke同步配置数据,刷新多个服务器上的缓存,当然如果用分布式缓存是不是更好
!
使用Spring HttpInvoke,你可以调用远程接口,进行数据交互、业务逻辑操作等等。
废话不说了,上代码!
用户操作接口:
用户类,注意实现Serializable接口,这是执行远程调用传递数据对象的第一要求——数据对象必须实现Serializable接口,因为,要执行序列化/反序列化操作!
覆盖toString()方法,输出用户信息!
再看UserServiceImpl实现:
只把用户信息打出来即可说明调用效果!
看applicationContext.xml
我们要把userService暴露出去,这样外部就可以通过http接口调用这个接口的实现了。
说说HttpInvokerServiceExporter,这个类用来在服务器端包装需要暴露的接口。
熟悉service,定义具体的实现类!
熟悉serviceInterface指向需要暴露的接口,注意使用value标注接口名称!
最后再看servlet.xml配置
直接将请求指向刚才配置的userService
现在我们之间访问一下http://localhost:8080/spring/service/
这就说明,服务器端配置已经成功了!如果在日志中频繁得到这种异常,那很可能服务器被恶意访问了!
再看客户端实现:
我们做了什么?Nothing!就跟调用一般Spring容器中的实现一样!
再看applicationContext.xml:
这里我们可以通过Spring容器调用userService,而实际上,他是一个HttpInvokerProxyFactoryBean,在这个配置里,定义了访问地址serviceUrl,和访问接口serviceInterface。
执行测试!
如果我们这样写,其实默认调用了SimpleHttpInvokerRequestExecutor做实现,这个实现恐怕只能作为演示来用!
这也是效率问题所在!!!
为提高效率,应该通过Commons-HttpClient!
我们需要做什么?导入这个jar,改改xml就行!
通过HttpClient,我们可以配置超时时间timeout和连接超时connectionTimeout两个属性,这样,服务器执行操作时,如果超时就可以强行释放连接,这样可怜的tomcat不会因为HttpInvoke连接不释放而被累死!
回头看了一眼我N多年前的代码,万岁,我当时确实是这么实现的!好在没有犯低级错误!!!
执行操作!
这时,转为org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor实现了!
不过同事认为,这个效率还是不够高!!!
再改,改什么?还是xml!
改用MultiThreadedHttpConnectionManager,多线程!!!
测试就不说了,实践证明:
默认实现,服务器平均10s左右才能响应一个请求。
多线程实现,服务器平均20ms左右响应一个请求。
这简直不是一个数量级!!!
注意:在HttpClient的3.1版本中,已不支持如下配置,相应的方法已经废弃!
如果仔细看看文档,
commons 系列的实现怎么会不考虑多线程呢?人家默认实现就是多线程的!同事多虑了!
当然,同事还补充了一句,需要控制连接数!
难怪,这里要设置
默认啥情况?
技高一筹!
赶紧记下来,供大家参考!
详情见附件!
许久没写博客了,今天终于舒展了一把!
我也顺道整理一下Spring HttpInvoke——那曾经最为熟悉的东西。
Spring HttpInvoke,一种较为常用的、基于Spring架构的服务器之间的远程调用实现,可以说是轻量级的RMI。
最初,我们使用Spring HttpInvoke同步配置数据,刷新多个服务器上的缓存,当然如果用分布式缓存是不是更好

使用Spring HttpInvoke,你可以调用远程接口,进行数据交互、业务逻辑操作等等。
废话不说了,上代码!
用户操作接口:
/** * @author <a href="mailto:zlex.dongliang@gmail.com">梁栋</a> * @since 1.0 */ public interface UserService { /** * 获得用户 * * @param username * 用户名 * @return */ User getUser(String username); }
用户类,注意实现Serializable接口,这是执行远程调用传递数据对象的第一要求——数据对象必须实现Serializable接口,因为,要执行序列化/反序列化操作!
/** * @author <a href="mailto:zlex.dongliang@gmail.com">梁栋</a> * @since 1.0 */ public class User implements Serializable { private static final long serialVersionUID = 5590768569302443813L; private String username; private Date birthday; /** * @param username * @param birthday */ public User(String username, Date birthday) { this.username = username; this.birthday = birthday; } // 省略 /* * (non-Javadoc) * * @see java.lang.Object#toString() */ @Override public String toString() { return String.format("%s\t%s\t", username, birthday); } }
覆盖toString()方法,输出用户信息!
再看UserServiceImpl实现:
/** * @author <a href="mailto:zlex.dongliang@gmail.com">梁栋</a> * @since 1.0 */ public class UserServiceImpl implements UserService { private Logger logger = Logger.getLogger(UserServiceImpl.class); /* * (non-Javadoc) * * @see * org.zlex.spring.httpinvoke.service.UserService#getUser(java.lang.String) */ @Override public User getUser(String username) { if (logger.isDebugEnabled()) { logger.debug("username:[" + username + "]"); } User user = new User(username, new Date()); if (logger.isDebugEnabled()) { logger.debug("user:[" + user + "]"); } return user; } }
只把用户信息打出来即可说明调用效果!
看applicationContext.xml
<bean id="userService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> <property name="service"> <bean class="org.zlex.spring.httpinvoke.service.impl.UserServiceImpl" /> </property> <property name="serviceInterface" value="org.zlex.spring.httpinvoke.service.UserService" /> </bean>
我们要把userService暴露出去,这样外部就可以通过http接口调用这个接口的实现了。
说说HttpInvokerServiceExporter,这个类用来在服务器端包装需要暴露的接口。
熟悉service,定义具体的实现类!
<property name="service"> <bean class="org.zlex.spring.httpinvoke.service.impl.UserServiceImpl" /> </property>
熟悉serviceInterface指向需要暴露的接口,注意使用value标注接口名称!
<property name="serviceInterface" value="org.zlex.spring.httpinvoke.service.UserService" />
最后再看servlet.xml配置
<bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="urlMap"> <map> <entry key="*" value-ref="userService" /> </map> </property> </bean>
直接将请求指向刚才配置的userService
现在我们之间访问一下http://localhost:8080/spring/service/

这就说明,服务器端配置已经成功了!如果在日志中频繁得到这种异常,那很可能服务器被恶意访问了!
再看客户端实现:
/** * @author <a href="mailto:zlex.dongliang@gmail.com">梁栋</a> * @since 1.0 */ public class UserServiceTest { private Logger logger = Logger.getLogger(UserServiceTest.class); private ApplicationContext context; private UserService userService; @Before public void initialize() { context = new ClassPathXmlApplicationContext("applicationContext.xml"); userService = (UserService) context.getBean("userService"); } @Test public void getUser() { User user = userService.getUser("zlex"); if (logger.isDebugEnabled()) { logger.debug("user[" + user + "]"); } } }
我们做了什么?Nothing!就跟调用一般Spring容器中的实现一样!
再看applicationContext.xml:
<bean id="userService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"> <property name="serviceUrl" value="http://localhost:8080/spring/service" /> <property name="serviceInterface" value="org.zlex.spring.httpinvoke.service.UserService" /> </bean>
这里我们可以通过Spring容器调用userService,而实际上,他是一个HttpInvokerProxyFactoryBean,在这个配置里,定义了访问地址serviceUrl,和访问接口serviceInterface。
执行测试!

如果我们这样写,其实默认调用了SimpleHttpInvokerRequestExecutor做实现,这个实现恐怕只能作为演示来用!
这也是效率问题所在!!!
为提高效率,应该通过Commons-HttpClient!
我们需要做什么?导入这个jar,改改xml就行!
<bean id="userService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"> <property name="serviceUrl" value="http://localhost:8080/spring/service" /> <property name="serviceInterface" value="org.zlex.spring.httpinvoke.service.UserService" /> <property name="httpInvokerRequestExecutor"> <ref bean="httpInvokerRequestExecutor" /> </property> </bean> <bean id="httpInvokerRequestExecutor" class="org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor"> <property name="httpClient"> <bean class="org.apache.commons.httpclient.HttpClient"> <property name="connectionTimeout" value="2000" /> <property name="timeout" value="5000" /> </bean> </property> </bean>
通过HttpClient,我们可以配置超时时间timeout和连接超时connectionTimeout两个属性,这样,服务器执行操作时,如果超时就可以强行释放连接,这样可怜的tomcat不会因为HttpInvoke连接不释放而被累死!

回头看了一眼我N多年前的代码,万岁,我当时确实是这么实现的!好在没有犯低级错误!!!
执行操作!

这时,转为org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor实现了!
不过同事认为,这个效率还是不够高!!!
再改,改什么?还是xml!
<bean id="httpInvokerRequestExecutor" class="org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor"> <property name="httpClient"> <bean class="org.apache.commons.httpclient.HttpClient"> <property name="connectionTimeout" value="2000" /> <property name="timeout" value="5000" /> <property name="httpConnectionManager"> <ref bean="multiThreadedHttpConnectionManager" /> </property> </bean> </property> </bean> <bean id="multiThreadedHttpConnectionManager" class="org.apache.commons.httpclient.MultiThreadedHttpConnectionManager"> <property name="params"> <bean class="org.apache.commons.httpclient.params.HttpConnectionManagerParams"> <property name="maxTotalConnections" value="600" /> <property name="defaultMaxConnectionsPerHost" value="512" /> </bean> </property> </bean>
改用MultiThreadedHttpConnectionManager,多线程!!!
测试就不说了,实践证明:
默认实现,服务器平均10s左右才能响应一个请求。
多线程实现,服务器平均20ms左右响应一个请求。
这简直不是一个数量级!!!
注意:在HttpClient的3.1版本中,已不支持如下配置,相应的方法已经废弃!
<property name="connectionTimeout" value="2000" /> <property name="timeout" value="5000" />
如果仔细看看文档,
引用
HttpClient that uses a default MultiThreadedHttpConnectionManager.
commons 系列的实现怎么会不考虑多线程呢?人家默认实现就是多线程的!同事多虑了!
当然,同事还补充了一句,需要控制连接数!
难怪,这里要设置
<bean class="org.apache.commons.httpclient.params.HttpConnectionManagerParams"> <property name="maxTotalConnections" value="600" /> <property name="defaultMaxConnectionsPerHost" value="512" /> </bean>
默认啥情况?
引用
maxConnectionsPerHost 每个主机的最大并行链接数,默认为2
public static final int DEFAULT_MAX_HOST_CONNECTIONS = 2;
maxTotalConnections 客户端总并行链接最大数,默认为20
public static final int DEFAULT_MAX_TOTAL_CONNECTIONS = 20;
public static final int DEFAULT_MAX_HOST_CONNECTIONS = 2;
maxTotalConnections 客户端总并行链接最大数,默认为20
public static final int DEFAULT_MAX_TOTAL_CONNECTIONS = 20;
技高一筹!

赶紧记下来,供大家参考!

详情见附件!

许久没写博客了,今天终于舒展了一把!

评论
8 楼
jd2bs
2015-05-12
3.1版本,俩个超时时间已经移到params里面了
client.getHttpConnectionManager().getParams()
.setConnectionTimeout(3000);
client.getHttpConnectionManager().getParams().setSoTimeout(3000);
client.getHttpConnectionManager().getParams()
.setConnectionTimeout(3000);
client.getHttpConnectionManager().getParams().setSoTimeout(3000);
7 楼
icur
2011-04-27
楼主写的不错哦
6 楼
wu_yong988
2011-03-30
不错,楼主,学习啦
5 楼
qkjava
2011-01-05
这个为工程与项目间的关系,既代码的模块化提供了一个很好的解决方案。
如果我们把代码归为工程,而市场认为是个项目的话。
市场所推的一个项目由若干个 工程模块来组成。
它比webservice更好的解决模块化问题。
如果我们把代码归为工程,而市场认为是个项目的话。
市场所推的一个项目由若干个 工程模块来组成。
它比webservice更好的解决模块化问题。
4 楼
newwpp
2010-12-23
受用 正好用到
3 楼
ilovehome
2010-07-02
不错,

2 楼
ligh0209
2010-07-01

1 楼
sdtm1016
2010-07-01

发表评论
-
征服 Redis + Jedis + Spring (三)—— 列表操作
2013-03-06 16:16 84159一开始以为Spring下操 ... -
Memcached笔记——(四)应对高并发攻击
2012-09-13 09:48 29108近半个月过得很痛苦,主要是产品上线后,引来无数机器用户恶意 ... -
征服 Redis + Jedis + Spring (二)—— 哈希表操作(HMGET HMSET)
2012-08-29 18:29 82452不得不说,用哈希操作来存对象,有点自讨苦吃! 不过,既然 ... -
征服 Redis + Jedis + Spring (一)—— 配置&常规操作(GET SET DEL)
2012-08-29 16:30 157713有日子没写博客了,真的是忙得要疯掉。 完成项目基础架构搭建 ... -
Spring 注解学习手札(八)补遗——@ExceptionHandler
2012-08-17 18:35 84377Spring注解,改变了我的 ... -
Spring 注解学习手札(七) 补遗——@ResponseBody,@RequestBody,@PathVariable
2012-08-10 21:27 440482最近需要做些接口服务,服务协议定为JSON,为了整合在Spri ... -
征服 Kestrel + XMemcached + Spring TaskExecutor
2012-07-30 14:43 6298上一篇征服 Kestrel + XMemcached只是对Ke ... -
征服Spring AOP—— @AspectJ
2012-04-10 12:01 18787接N年前写的一篇Spring AOP相关的内容征服Spring ... -
Memcached笔记——(二)XMemcached&Spring集成
2012-04-01 09:55 42439今天研究Memcached的Java的Client,使用XMe ... -
Spring util
2011-02-24 12:02 01,<util:constant/> 取代了之前通 ... -
Spring 注解学习手札(六) 测试
2010-02-05 16:28 53268既然系统基于注解自成一体,那么基于Spring的测试是否可以依 ... -
Spring 注解学习手札(五) 业务层事务处理
2010-02-04 16:11 25453控制器层、持久层都有 ... -
Spring 注解学习手札(四) 持久层浅析
2010-01-29 11:11 22715今天,我们玩玩数据库,搞搞持久层。不搞太复杂的东西,Sprin ... -
Spring 注解学习手札(三) 表单页面处理
2010-01-26 15:21 40618昨天小歇一天,看着两篇博客迅速飙升的点击率,十分欣慰。今天来研 ... -
Spring 注解学习手札(二) 控制层梳理
2010-01-24 15:53 36672昨天对Spring注解有了一 ... -
Spring 注解学习手札(一) 构建简单Web应用
2010-01-23 13:40 83893近来工作发生了一些变化,有必要学习一下Spring注解了! ... -
征服Spring AOP—— Schema
2008-09-03 17:41 6508自从开始使用Spring,就接触到AOP,但一直未能深入,沉淀 ... -
关于Spring中Commons Validator的使用说明
2008-09-01 09:57 8217关于Spring中Commons Validator的使用说明 ... -
acegi 我该从哪里取到用户的信息
2006-09-21 17:32 5855项目需要 用acegi做为安全屏障,按acegi 1.0.1 ...
相关推荐
- 使用Spring的HttpInvoke实现,适合提供者数量多于消费者的场景,尤其是需要为应用程序和浏览器JS调用的情况。基于HTTP的短连接传输。 5. **Hessian协议**: - 基于HTTP通讯,使用Servlet暴露服务,Dubbo内嵌...
内容概要:本文详细探讨了在Simulink环境中构建的风火水储联合调频系统中,储能系统的荷电状态(SOC)对区域控制偏差(ACE)的影响。文中通过具体案例和MATLAB代码展示了储能系统在不同SOC水平下的表现及其对系统稳定性的作用。同时,文章比较了储能单独调频与风火水储联合调频的效果,强调了储能系统在应对风电波动性和提高系统响应速度方面的重要作用。此外,作者提出了针对SOC变化率的参数整定方法以及多电源协同工作的优化策略,旨在减少ACE波动并确保系统稳定运行。 适合人群:从事电力系统调频研究的专业人士,尤其是熟悉Simulink仿真工具的研究人员和技术人员。 使用场景及目标:适用于希望深入了解储能系统在电力系统调频中作用的研究者和技术人员,目标是通过合理的SOC管理和多电源协同工作,优化调频效果,提高系统稳定性。 其他说明:文章提供了详细的MATLAB代码片段,帮助读者更好地理解和应用所讨论的概念。同时,文中提到的实际案例和仿真结果为理论分析提供了有力支持。
内容概要:本文深入探讨了欧姆龙PLC NJ系列中大型程序中结构化编程与面向对象编程的结合及其应用。首先介绍了结构化编程作为程序框架的基础,通过功能块(FB)实现清晰的程序结构和流程控制。接着阐述了面向对象编程的理念,将现实世界的对象映射到程序中,利用类的概念实现模块化和可扩展性。两者结合提高了程序的容错率,增强了程序的稳定性和可维护性。文中通过多个实际案例展示了如何在工业自动化领域中应用这两种编程方法,如电机控制、设备类的创建、异常处理机制、接口实现多态性、配方管理和报警处理等。 适合人群:从事工业自动化领域的工程师和技术人员,尤其是那些希望提升PLC编程技能的人群。 使用场景及目标:适用于需要优化PLC程序结构、提高程序可靠性和可维护性的场合。目标是帮助工程师掌握结构化编程和面向对象编程的技巧,从而写出更加高效、稳定的PLC程序。 其他说明:文章强调了在实际项目中灵活运用两种编程方法的重要性,并提醒读者注意实时性要求高的动作控制应采用结构化编程,而工艺逻辑和HMI交互则更适合面向对象编程。
matlab与聚类分析。根据我国历年职工人数(单位:万人),使用有序样品的fisher法聚类。
卡尔曼滤波生成航迹测量程序
内容概要:本文详细介绍了利用格子玻尔兹曼方法(LBM)对多孔电极浸润特性的模拟研究。首先阐述了LBM的基本原理,包括碰撞和迁移两个关键步骤,并提供了相应的Python伪代码。接着讨论了如何处理多孔介质中的固体边界,特别是通过随机算法生成孔隙结构以及结合CT扫描数据进行三维重构的方法。文中还探讨了表面张力、接触角等因素对浸润过程的影响,并给出了具体的数学表达式。此外,文章提到了并行计算的应用,如使用CUDA加速大规模网格计算,以提高模拟效率。最后,作者分享了一些实用技巧,如通过调整松弛时间和润湿性参数来优化模拟效果,并强调了LBM在处理复杂几何结构方面的优势。 适合人群:从事电池研发、材料科学领域的研究人员和技术人员,尤其是关注多孔电极浸润性和电解液扩散机制的人群。 使用场景及目标:适用于希望深入了解多孔电极内部流体动力学行为的研究者,旨在帮助他们更好地理解和预测电极材料的浸润特性,从而改进电池设计和性能。 其他说明:尽管LBM在处理多孔介质方面表现出色,但在某些极端条件下仍需引入额外的修正项。同时,参数的选择和边界条件的设定对最终结果有着重要影响,因此需要谨慎对待。
内容概要:本文详细介绍了在Zynq扩展口上使用FPGA和W5500实现TCP网络通信的过程。作者通过一系列实验和技术手段,解决了多个实际问题,最终实现了稳定的数据传输。主要内容包括:硬件搭建(SPI接口配置)、数据回环处理、压力测试及优化、多路复用扩展以及上位机测试脚本的编写。文中提供了大量Verilog代码片段,展示了如何通过状态机控制SPI通信、优化数据缓存管理、处理中断等问题。 适合人群:对FPGA开发和网络通信感兴趣的工程师,尤其是有一定Verilog编程基础的研发人员。 使用场景及目标:适用于需要在嵌入式系统中实现高效、稳定的TCP通信的应用场景。目标是帮助读者掌握FPGA与W5500结合进行网络通信的具体实现方法和技术细节。 其他说明:文章不仅提供了详细的代码实现,还分享了许多实践经验,如硬件连接注意事项、信号完整性问题的解决方案等。此外,作者还提到了未来的工作方向,如UDP组播和QoS优先级控制的实现。
python3.10以上 可安装pyside6(类似pyqt),具体安装操作步骤
内容概要:本文详细介绍了利用有限差分时域法(FDTD)进行可调谐石墨烯超材料吸收体的设计与仿真。文中解释了石墨烯超材料的基本结构(三层“三明治”结构)、关键参数(如化学势、周期、厚度等)及其对吸收性能的影响。同时展示了如何通过调整石墨烯的化学势来实现吸收峰的位置和强度的变化,以及如何优化结构参数以获得最佳的吸收效果。此外,还提供了具体的代码示例,帮助读者理解和重现相关实验结果。 适合人群:从事纳米光子学、超材料研究的专业人士,尤其是对石墨烯基超材料感兴趣的科研工作者和技术开发者。 使用场景及目标:适用于希望深入了解石墨烯超材料的工作原理及其潜在应用场景的研究人员;旨在探索新型可调谐光学器件的设计思路和发展方向。 其他说明:文中不仅分享了理论知识,还包括了许多实践经验,如避免常见错误、提高仿真相关效率的小技巧等。对于想要将研究成果应用于实际产品的团队来说,这些细节非常有价值。
随机生成2字,3字,4字,5字,6字,7字,8字,9字,10字的中文词组20个
内容概要:本文详细探讨了智能座舱域控设计的发展历程和技术趋势。首先介绍了智能座舱从被动式交互到主动式交互的技术演变,包括硬件和交互方式的进步。随后,文章重点讨论了智能座舱功能发展趋势,涵盖车载显示技术的多屏化、大屏化和高端化,以及SoC芯片的多核异构架构和算力融合,强调了其在智能座舱中的核心作用。此外,还阐述了电子电气架构从分布式向集成化的转型,分析了其面临的挑战和未来趋势。最后,基于当前智能座舱的发展需求,提出了一种基于双片龍鷹一号芯片的新域控平台设计方案,详细描述了其硬件设计实现方案,旨在提供高性能、高可靠性的智能座舱解决方案。 适合人群:汽车电子工程师、智能座舱研发人员及相关领域的技术人员。 使用场景及目标:①帮助读者理解智能座舱的技术发展历程及其未来发展方向;②为智能座舱域控平台的设计和开发提供参考和技术支持;③探讨电子电气架构的转型对汽车行业的影响及应对策略。 其他说明:文章结合实际案例和技术数据,深入浅出地解释了智能座舱的各项技术细节,不仅提供了理论指导,还具有较强的实践意义。通过对智能座舱域控平台的全面剖析,有助于推动智能座舱技术的创新发展,提升用户体验。
内容概要:本文详细介绍了多智能体协同编队控制的技术原理及其应用实例。首先通过生动形象的例子解释了编队控制的核心概念,如一致性算法、虚拟结构法和Leader-Follower模式。接着深入探讨了如何用Python实现基础的一致性控制,以及如何通过调整参数(如Kp、Ka)来优化编队效果。文中还讨论了实际工程中常见的问题,如通信延迟、避障策略和动态拓扑变化,并给出了相应的解决方案。最后,强调了参数调试的重要性,并分享了一些实用技巧,如预测补偿、力场融合算法和分布式控制策略。 适合人群:对多智能体系统、无人机编队控制感兴趣的科研人员、工程师和技术爱好者。 使用场景及目标:适用于希望深入了解多智能体协同编队控制理论并能够将其应用于实际项目的研究人员和开发者。目标是帮助读者掌握编队控制的关键技术和实现方法,提高系统的稳定性和可靠性。 其他说明:文章不仅提供了详细的理论讲解,还附有具体的代码示例,便于读者理解和实践。同时,作者结合自身经验分享了许多宝贵的调试技巧和注意事项,有助于读者在实际应用中少走弯路。
评估管线钢环焊缝质量及其对氢脆的敏感性.pptx
C盘清理bat脚本自动清理C盘垃圾文件
GBT21266-2007 辣椒及辣椒制品中辣椒素类物质测定及辣度表示方法
弹跳球 XNA 游戏项目。演示如何使用 C# 在 Visual Studio XNA 中构建类似 arkanoiddx-ball 的游戏。
内容概要:文章全面解析了宇树科技人形机器人的发展现状、技术实力、市场炒作现象及其应用前景和面临的挑战。宇树科技成立于2016年,凭借春晚舞台的惊艳亮相和社交媒体的热议迅速走红,其人形机器人具备先进的运动控制算法、传感器技术和仿生结构设计。然而,市场炒作现象如高价租赁、二手市场炒作和虚假宣传等影响了市场秩序。尽管存在炒作,人形机器人在工业、服务和家庭领域仍具广阔前景,但也面临技术升级、成本控制、安全性和政策监管等挑战。 适合人群:对机器人技术、人工智能以及科技发展趋势感兴趣的读者,包括科技爱好者、投资者和相关行业的从业者。 使用场景及目标:①帮助读者了解宇树科技人形机器人的技术特点和发展历程;②揭示市场炒作现象及其影响;③探讨人形机器人的应用前景和面临的挑战。 其他说明:文章强调了宇树科技人形机器人在技术上的突破和市场上的表现,同时也提醒读者关注市场炒作现象带来的风险,呼吁各方共同努力推动人形机器人产业健康发展。
msvcp140.dll丢失怎样修复
超透镜是一种将具有特殊电磁特性的纳米结构、按照一定方式进行排列的二维平面透镜,可实现对入射光振幅、相位、偏振等参量的灵活调控,在镜头模组、全息光学、AR/VR等方面具有重要应用,具有颠覆传统光学行业的潜力。 目前,超透镜解决方案的市场处于起步阶段,企业根据客户的具体需求和应用场景为其定制专用超透镜或超透镜产品。 根据QYResearch最新调研报告显示,预计2031年全球超透镜解决方案市场规模将达到29.26亿美元,未来几年年复合增长率CAGR为79.55%。 全球范围内,超透镜解决方案主要生产商包括Metalenz, Inc., Radiant Opto-Electronics (NIL Technology),迈塔兰斯、纳境科技、山河元景等,其中前五大厂商占有大约77.84%的市场份额。 目前,全球核心厂商主要分布在欧美和亚太地区。 就产品类型而言,目前红外超透镜解决方案是最主要的细分产品,占据大约96.76%的份额。 就产品类型而言,目前消费电子是最主要的需求来源,占据大约36.27%的份额。 主要驱动因素: 独特性能优势:超透镜解决方案具有更轻薄、成本更低、成像更好、更易集成、更高效及更易自由设计等优势。能以微米级厚度实现传统厘米级透镜功能,还可集多个光学元件功能于一身,大幅减小成像系统体积、重量,简化结构并优化性能。 技术创新推动:超透镜解决方案技术不断取得进步,设计技术和工艺水平持续提升,其性能和稳定性得以不断提高。制造工艺方面,电子束光刻等多种技术应用到超透镜解决方案生产中,推动超透镜解决方案向更高分辨率、更高产量、更大面积、更高性能的方向发展。 市场需求增长:消费电子、汽车电子、医疗、工业等众多领域快速发展,对高精度、高性能光学器件需求不断增加。如在手机摄像头中可缩小模组体积、提升成像分辨率和降低成本;在汽车电子领域能提高车载摄像头、激光雷达等传感器性能。