京东面试:SpringBoot同时可以处理多少请求?

springboot · 浏览次数 : 0

小编点评

**1. Web三大容器** * Tomcat:最广泛使用,成熟稳定,适合大型应用。 * Undertow:高性能、低内存占用,适合处理高并发短连接场景。 * Jetty:开源、轻量级,适合快速开发和轻量级部署。 **2. 最大连接数和最大等待数** * 默认情况下,Tomcat 的最大连接数为 8192,最大等待数为 100。 **3. 设置Web容器** * 可以通过 pom.xml 文件中的 `server.tomcat` 设置容器类型,例如 `tomcat` 或 `jetty`. **4. 设置容器为Jetty** * 需要移除 `spring-boot-starter-tomcat`依赖,并添加 `org.springframework.boot:spring-boot-starter-jetty`依赖。 **5. 设置容器为Undertow** * 需要移除 `spring-boot-starter-tomcat`依赖,并添加 `org.springframework.boot:spring-boot-starter-undertow`依赖。 **6. Tomcat默认的最大连接数为 8192 的原因** 由于 Tomcat 是 Apache 软件基金会下的开源项目,其最大连接数取决于操作系统和服务器硬件资源。默认情况下,Tomcat 的最大连接数设置为 8192。

正文

Spring Boot 作为 Java 开发中必备的框架,它为开发者提供了高效且易用的开发工具,所以和它相关的面试题自然也很重要,咱们今天就来看这道经典的面试题:SpringBoot同时可以处理多少个请求 ?

准确的来说,Spring Boot 同时可以处理多少个请求,并不取决于 Spring Boot 框架本身,而是取决于其内置的 Web 容器(因为 Web 容器的行为,决定了 Spring Boot 的行为,所以咱们姑且认为两个问题的回答是一样的)。

1.Web三大容器

Web 容器目前也是三分天下,市面上最常见的三种 Web 容器分别是:Tomcat、Undertow 和 Jetty,其中 Tomcat 为 Spring Boot 框架默认的 Web 容器。

它们三者的区别如下:

  • Tomcat 是 Apache 软件基金会下的开源项目,是最广泛使用的 Servlet 容器之一,完全实现了 Java Servlet 和 JavaServer Pages(JSP)规范。它不仅是一个 Servlet 容器,也是一个轻量级的应用服务器,尽管相比其他轻量级服务器,Tomcat 被认为是稍微重一些的。Tomcat 支持众多的企业级特性,如 SSL、连接池等,适合运行大型的、复杂的企业级应用。它的稳定性和成熟度经过了多年的企业级应用验证,因此在很多企业中作为首选的 Web 容器。
  • Undertow 是 Red Hat(红帽公司)开发的一个灵活的、高性能的 Web 服务器和反向代理服务器,它是 WildFly 应用服务器的默认 Web 容器。Undertow 设计上注重低内存占用和高并发处理能力,尤其擅长处理大量的短连接场景,比如 RESTful API 服务。Undertow 支持 Servlet 3.1、WebSocket以及非阻塞 IO(NIO),并且是支持 HTTP/2 协议的现代服务器之一。它的设计理念在于提供一个模块化、可嵌入式的解决方案,易于集成到现有的系统中,同时也适合微服务架构。
  • Jetty 是一个开源的、轻量级的 Web 服务器和 Servlet 容器,由 Eclipse 基金会维护。它以其可嵌入式、高度可配置性著称,常用于需要快速启动和轻量级部署的场景,比如开发阶段、测试环境或轻量级应用。Jetty 也支持 Servlet 规范和 WebSocket,且同样基于 NIO,使得它在处理大量并发连接时表现出色。Jetty 设计上强调灵活性和可扩展性,易于通过 API 定制以满足特定需求,因此在云环境、持续集成、DevOps 等领域很受欢迎。

总的来说,Tomcat 因其成熟稳定和企业级特性适用于大型应用;Undertow 以高性能和低内存占用见长,特别适合处理高并发短连接场景;而 Jetty 则以轻量、灵活、易于嵌入为特点,适合快速开发和轻量级部署。

2.最大连接数和最大等待数

以 Spring Boot 框架默认的 Web 容器 Tomcat 为例,它能够同时处理多少个请求,其实是在 Spring Boot 框架中的 spring-configuration-metadata.json 文件中配置着,如下图所示:
image.png
打开此文件,搜索“server.tomcat.max-connections”(Tomcat 最大连接数)会得到以下结果:
image.png
也就是说,默认情况下 Tomcat 允许的最大连接数是 8192(=8*1024)个。

那么,此时有人可能会认为,默认情况下 Spring Boot 同时能处理的请求数应该是 8192,如果你也是这样认为,那你就错了。为什么呢?

因为,虽然 Tomcat 可以允许最大的连接数是 8192,但是 Tomcat 还有一个最大等待数,也就是说,如果达到了 8192 之后,还有一个等待队列可以存放请求的连接,所以,Spring Boot 可以同时处理多少个连接,等于 Tomcat 的最大连接数加 Tomcat 的最大等待数

那么,最大等待数是多少呢?

我们继续在 spring-configuration-metadata.json 文件中,搜索“server.tomcat.accept-count”(Tomcat 最大等待数),搜索结果如下图所示:
image.png
也就是说,默认情况下,Tomcat 最大等待数为 100 个。

3.同时处理请求数

所以得出结论:默认情况下 Spring Boot 能够同时处理的请求数=最大连接数(8192)+最大等待数(100),结果为 8292 个。

当然,这两个值是可以在 Spring Boot 配置文件中修改的,如下配置所示:

server:
  tomcat:
    max-connections: 2000 # 最大连接数
    accept-count: 200 # 最大等待数

4.扩展知识:设置Web容器

Spring Boot 框架如何设置 Web 容器为 Jetty 或 Undertow 呢?接下来,我们来看一下。

4.1 设置容器为Jetty

要设置 Spring Boot 框架的 Web 容器为 Jetty,只需要修改 pom.xml 文件即可,如下配置所示:

<dependencies>
    <!-- Spring Boot Starter Web 但排除Tomcat -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <!-- 排除Tomcat -->
        <exclusions>
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <!-- 添加Jetty起步依赖 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-jetty</artifactId>
    </dependency>
</dependencies>

也就是说,只需要将默认的 tomcat 排除掉,添加 jetty 的依赖即可。

4.2 设置容器为Undertow

要设置 Spring Boot 框架的 Web 容器为 Undertow 的思路和上面 Jetty 的实现思路相同,只需要修改 pom.xml 文件即可,如下配置所示:

<dependencies>
    <!-- Spring Boot Starter Web 但排除Tomcat -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-starter-tomcat</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <!-- 添加Undertow起步依赖 -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-undertow</artifactId>
    </dependency>
</dependencies>

课后思考

为什么 Tomcat 默认的最大连接数为 8192 呢?Jetty 和 Undertow 同时又能处理多少个请求呢?

本文已收录到我的面试小站 www.javacn.site,其中包含的内容有:Redis、JVM、并发、并发、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、设计模式、消息队列等模块。

与京东面试:SpringBoot同时可以处理多少请求?相似的内容:

京东面试:SpringBoot同时可以处理多少请求?

Spring Boot 作为 Java 开发中必备的框架,它为开发者提供了高效且易用的开发工具,所以和它相关的面试题自然也很重要,咱们今天就来看这道经典的面试题:SpringBoot同时可以处理多少个请求 ? 准确的来说,Spring Boot 同时可以处理多少个请求,并不取决于 Spring Bo

京东面试:如何进行JVM调优?

JVM 调优是一个很大的话题,在回答“如何进行 JVM 调优?”之前,首先我们要回答一个更为关键的问题,那就是,我们为什么要进行 JVM 调优? 只有知道了为什么要进行 JVM 调优之后,你才能准确的回答出来如何进行 JVM 调优? 要进行 JVM 调优无非就是以下两种情况: 目标驱动型的 JVM

抢先看!美团、京东、360等大厂面试题解析,技术面试必备。

技术面试必备!美团、京东、360等大厂面试题详解,让你轻松应对各大公司面试挑战! 往期硬核面经 哦耶!冲进腾讯了! 牛逼!上岸腾讯互娱和腾讯TEG! 腾讯的面试,强度拉满! 前几篇文章分享了上岸腾讯的最新面经。 不少粉丝股东留言说别只发腾讯的啦,其他大厂的也安排一些吧,比如美团、360、京东的。 必

如何把一个接口设计好?

如何设计一个接口?是在我们日常开发或者面试时经常问及的一个话题。很多人觉得这不就是CRUD,能实现不就行了。单纯实现来说,并非难事,但要做到易用、易扩展、易维护并不是一件简单的事。这里并不强调一些个接口设计的原则或者设计方法,仅从如何设计一个好的接口出发,简单讨论。

聊聊JDK1.0到JDK20的那些事儿

最近小组在开展读书角活动,我们小组选的是《深入理解JVM虚拟机》,相信这本书对于各位程序猿们都不陌生,我也是之前在学校准备面试期间大致读过一遍,emm时隔多日,对里面的知识也就模糊了。这次开始的时候从前面的JDK发展史和JVM虚拟机家族着手,之前都是粗略读过,这次通过查阅相关资料并收集在每一个JDK版本演化期间所发生的的一些趣闻,发现还是比较有意思的,以下是关于有关JDK发展史的总结分享。

一种面向业务配置基于JSF广播定时生效的工具

作者:京东物流 王北永 姚再毅 李振 1 背景 目前,ducc实现了实时近乎所有配置动态生效的场景,但是配置是否实时生效,不能直观展示每个机器上jvm内对象对应的参数是否已变更为准确的值,大部分时候需要查看日志确认是否生效。 2 技术依赖 1)Jsf:京东RPC框架,用作机器之间的通讯工具 2)re

一文了解电商大促系统的高可用保障思路

本文面向受众可以是运营、可以是产品、也可以是研发、测试人员,作者希望通过如下思路(知历史->清家底->明目标->定战略->做战术->促成长)帮助大家能够了解电商大促系统的高可用保障,减少哪些高深莫测的黑话和高大尚的论调,而是希望有个体系化的知识让读者有所得。

一种面向后端的微服务低代码平台架构设计

结合京东业务研发实际情况,针对后端研发人员,设计一个微服务低代码平台,助力更高效低交付业务需求。现已结业,将我在本次项目中沉淀设计出的设计文档整理成文,期待与大家有进一步的碰撞沟通

全球首个面向遥感任务设计的亿级视觉Transformer大模型

深度学习在很大程度上影响了遥感影像分析领域的研究。然而,大多数现有的遥感深度模型都是用ImageNet预训练权重初始化的,其中自然图像不可避免地与航拍图像相比存在较大的域差距,这可能会限制下游遥感场景任务上的微调性能。

面向状态机编程:复杂业务逻辑应对之道

在研发项目中,经常能遇到复杂的状态流转类的业务场景,比如游戏编程中NPC的跳跃、前进、转向等状态变化,电商领域订单的状态变化等。这类情况其实可以有一种优雅的实现方法:状态机。本文重点介绍有限状态机,并结合具体项目,通过状态机的应用将状态和业务逻辑解耦,便于简化复杂业务逻辑,降低理解成本。另外,重点讲解如何优雅的解决更广泛的复杂业务问题。