springMvc与springWebflux简介

 

1.个人理解

同步:一直等待得到结果。

异步:一个线程接受请求后 直接返回 并不会得到结果 等后端处理完毕之后 在选择一个线程返回结果。

阻塞:等待着一个请求完成 挂起线程 没完成的话下一个请求不执行

非阻塞:在一个请求执行时并且没得到结果 不会阻塞改线程

1.springMvc

springMvc一般会部署在tomcat上,而tomcat一般会建立一个线程池,每发送一个请求,就会为请求绑定一个线程,对于每个线程是同步阻塞的。(也可以配置成异步 这样会提升吞吐量) 当请求过多,线程池中线程消耗完毕之后,服务就会阻塞,这样会大大影响,服务的效率,同时因为线程池也太过沉重,这样就引出了webFlux。

2.springWebFlux

WebFlux只是响应式编程中的一部分(在Web控制端),所以一般我们用它与SpringMVC来对比,而webFlux通过数据流和响应式编程使服务异步非阻塞。

2.同步、异步、阻塞、非阻塞解释

老张爱喝茶,废话不说,煮开水。
出场人物:老张,水壶两把(普通水壶,简称水壶;会响的水壶,简称响水壶)。
1 老张把水壶放到火上,立等水开。(同步阻塞)
老张觉得自己有点傻
2 老张把水壶放到火上,去客厅看电视,时不时去厨房看看水开没有。(同步非阻塞)
老张还是觉得自己有点傻,于是变高端了,买了把会响笛的那种水壶。水开之后,能大声发出嘀~~~~的噪音。
3 老张把响水壶放到火上,立等水开。(异步阻塞)
老张觉得这样傻等意义不大
4 老张把响水壶放到火上,去客厅看电视,水壶响之前不再去看它了,响了再去拿壶。(异步非阻塞)
老张觉得自己聪明了。

所谓同步异步,只是对于水壶而言。
普通水壶,同步;响水壶,异步。
虽然都能干活,但响水壶可以在自己完工之后,提示老张水开了。这是普通水壶所不能及的。
同步只能让调用者去轮询自己(情况2中),造成老张效率的低下。

所谓阻塞非阻塞,仅仅对于老张而言。
立等的老张,阻塞;看电视的老张,非阻塞。
情况1和情况3中老张就是阻塞的,媳妇喊他都不知道。虽然3中响水壶是异步的,可对于立等的老张没有太大的意义。所以一般异步是配合非阻塞使用的,这样才能发挥异步的效用。

Spring MVCSpring WebFlux是两种不同的Web开发框架。它们的主要区别在于底层的线程模型和编程模式。 1. 线程模型: - Spring MVC使用传统的基于Servlet的线程模型。每个请求都会分配一个独立的线程,该线程在处理请求期间一直保持活动状态,直到响应返回给客户端。 - Spring WebFlux使用基于事件驱动的非阻塞线程模型。它建立在Reactor库之上,使用少量的线程处理大量的并发连接,通过异步非阻塞方式提供高吞吐量和可伸缩性。 2. 编程模式: - Spring MVC采用同步编程模式,其中请求在处理期间会阻塞线程,并等待操作完成。 - Spring WebFlux采用异步编程模式,其中请求在处理期间不会阻塞线程,而是通过回调、Future或者Reactor中的Mono和Flux等异步机制进行处理。 3. 响应式支持: - Spring MVC是基于Servlet规范的,并且大部分API都是同步的。它可以通过使用一些非阻塞I/O库来提高并发性能,但不能实现真正的响应式编程。 - Spring WebFlux是基于Reactive Streams规范的,完全支持响应式编程。它可以利用Reactor库提供的异步、非阻塞和响应式能力来处理大量的并发请求。 总的来说,Spring MVC适合传统的同步编程模型,在处理相对较小的并发请求时表现良好。而Spring WebFlux则适用于对高吞吐量和可伸缩性有更高要求的场景,它提供了更好的性能和响应能力,尤其是在处理I/O密集型和长时间等待的操作时。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

小鲍侃java

请博主喝个可乐吧,可加微信面基

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值