Tomcat

典型回答 Tomcat是一个开源的Java Servlet容器和JavaServer Pages（JSP）引擎，Tomcat是一个Web应用程序服务器，它实现了Java Servlet和JSP规范，支持Java的Server-Side编程模型。它提供了一个Servlet容器，用于管理和执行Java Servlet，以及一个JSP引擎，用于编译和执行JSP页面。 **Tomcat与Web服务器（如Apache、Nginx等）之间通常是配合使用的，形成一个典型的应用服务器架构。**这种架构被称为"Tomcat-Apache联合部署"，它利用了两者的优势，提供更强大的功能和性能。 这种情况下，Apache充当反向代理服务器，负责接收客户端的请求并处理一部分静态内容的请求。然后，Apache将动态请求（如Java Servlet、JSP）转发给Tomcat进行处理。Apache与Tomcat之间的通信通常通过AJP协议（Apache JServ Protocol）或HTTP协议来实现。并且Apache也可以处理一些简单的操作，比如静态资源的访问，黑名单控制等。 这种架构的优势是，Apache作为前端服务器能够处理高并发的静态请求，而Tomcat作为应用服务器则专注于处理动态请求，提供Java Servlet和JSP的支持。这样分离静态和动态内容，使得整体的请求处理效率更高。

典型回答 Tomcat的类加载机制是指Tomcat在运行时如何加载和管理Java类。Tomcat的类加载机制的实现并没有严格遵守双亲委派原则，而是采用了一种层次化的类加载器结构，这种结构旨在提供更好的隔离性和灵活性，以支持多个Web应用程序的部署和运行。 ✅什么是双亲委派？如何破坏？ 关于Tomcat的ClassLoader的关系，网上有各种各样的图，但是大部分都是不对的。甚至有一些画完图之后竟然还能自圆其说。。。 下面这张图，是我基于Tomcat官网，以及源码总结之后的一张图（从Tomcat 6到Tomcat 10，都长这个样）： 但是，默认情况下，Server类加载器和Shared类加载器是未定义的，需要通过在conf/catalina.properties中定义server.loader和/或shared.loader属性的值，才会是这个更复杂的层次结构。 Server类加载器只对Tomcat内部可见，对于Web应用程序完全不可见。 Shared类加载器对所有Web应用程序可见，可以用于在所有Web应用程序之间共享代码。但是，对这些共享代码进行更新将需要重新启动Tomcat。 所以，真正的需要一定有的，并且我们通常需要关注的就是下面这个层级关系： 启动类加载器（Bootstrap ClassLoader）： 负责加载JVM自身的核心类库（如java.lang、java.util等）和JVM相关的类。启动类加载器是JVM的一部分，负责加载JVM运行所需的基础类。主要加载JRE中的lib包及lib/ext包下的内容 系统类加载器（System Class Loader），负载加载Tomcat内部的一些核心类库，这些类一般在$CATALINA_HOME/bin这个目录下， 一般包含bootstarap.jar、tomcat-juli.jar以及common-daemon.jar等。 公共类加载器（Common Class Loader）： 负责加载Tomcat的公共类和库，位于$CATALINA_HOME/lib目录下的JAR文件。这些类库是Tomcat启动时加载的，是整个Tomcat实例中共享的类。 Web应用程序类加载器（Webapp Class Loader）： 每个Web应用程序都有一个独立的Web应用程序类加载器，负责加载该Web应用程序的类和资源。它从$CATALINA_HOME/webapps/<webapp_name>/WEB-INF/classes目录和$CATALINA_HOME/webapps/<webapp_name>/WEB-INF/lib目录加载类和JAR文件。 扩展知识 Tomcat类加载机制 ✅Tomcat的类加载机制是怎么样的？

典型回答 想要详细了解Tomcat的启动流程， 可以通过代码来看，主要入口就是Bootstrap这个类中，主要就是三个方法，init，load和start，下图是别人总结的一张完整的流程图，大家可以看一下： 整个过程还是比较复杂的，我尝试着总结一下，方便大家理解和记忆，Tomcat的启动过程主要由以下几个步骤： bootstrap.init 加载启动类：加载启动相关的类加载器及类，创建Catelina对象。 bootstrap.load 加载配置文件：主要包括server.xml和web.xml，其中server.xml用于配置Tomcat的基础服务，如端口号、线程池等；web.xml用于配置Web应用程序的参数、Servlet和过滤器等信息。 初始化组件：依次初始化Tomcat的各个组件，包括Server、Service、Connector、Engine、Host和Context，它们都是Tomcat运行的重要组成部分。 bootstrap.start 启动服务：当所有组件初始化完成后，Tomcat会依次启动Connector、Engine、Host和Context，最终启动整个Tomcat服务。 部署应用：启动完成后，会扫描指定的Web应用程序目录，自动部署已经打包好的Web应用程序。 以上步骤执行完之后，一个web应用就启动了，后续有请求到达时，会根据请求的URL匹配相应的Context，然后将请求转发到相应的Servlet或JSP进行处理。

典型回答 ✅Tomcat中有哪些类加载器? 关于这个问题，网上有很多种说法，甚至我看过某国内非常知名的付费专栏中，关于这个点也并不是讲解的特别清楚。那么，这里我们先总结一下Tomcat的类加载机制，然后再来证明为啥我这么说： Tomcat的类加载机制，在默认情况下，是先把当前要加载的类委托给BootstrapClassLoader尝试加载，为了避免JRE中的核心类被我们应用自己给覆盖（如String等），Bootstrap如果无法加载，那么就由WebAppClassLoader尝试加载，如果无法加载，那么再委托通过双亲委派的方式向上委派给Common、System等类加载进行加载，即顺序为：****Bootstrap->WebApp->System->Common 上面的是默认情况，tomcat中有一个配置**<font style="color:#F38F39;">delegate</font>**，他的默认值是false，如果设置成true了，那么他就会严格遵守双亲委派，按照****Bootstrap->System->Common->WebApp的顺序进行加载。 talk is cheap，show me the code 以下是tomcat中WebappClassLoaderBase.java中loadClass的代码，我做了一些精简，并加了一些注释： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { //加锁，防止并发 synchronized (JreCompat.isGraalAvailable() ? this : getClassLoadingLock(name)) { if (log.isDebugEnabled()) { log.debug("loadClass(" + name + ", " + resolve + ")"); } Class<?> clazz = null; // ... // 检查本地缓存是否已加载该类，如果是，则直接返回缓存中的 Class 对象。 clazz = findLoadedClass0(name); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Returning class from cache"); } if (resolve) { resolveClass(clazz); } return clazz; } // 检查另一个类加载缓存，如果是GraalVM环境，直接返回缓存中的 Class 对象。 clazz = JreCompat.isGraalAvailable() ? null : findLoadedClass(name); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Returning class from cache"); } if (resolve) { resolveClass(clazz); } return clazz; } /* * 尝试使用Bootstrap类加载器加载类，以防止Web应用程序覆盖Java SE类。如果加载成功，则返回加载的 Class 对象。 */ String resourceName = binaryNameToPath(name, false); ClassLoader javaseLoader = getJavaseClassLoader(); boolean tryLoadingFromJavaseLoader; try { URL url = javaseLoader.getResource(resourceName); tryLoadingFromJavaseLoader = url != null; } catch (Throwable t) { ExceptionUtils.handleThrowable(t); tryLoadingFromJavaseLoader = true; } if (tryLoadingFromJavaseLoader) { try { clazz = javaseLoader.loadClass(name); if (clazz != null) { if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } } boolean delegateLoad = delegate || filter(name, true); // 根据 delegate 属性和其他条件判断是否应该委派加载给父类加载器。 // 如果需要委派，则直接先进行委派 if (delegateLoad) { if (log.isDebugEnabled()) { log.debug(" Delegating to parent classloader1 " + parent); } try { clazz = Class.forName(name, false, parent); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Loading class from parent"); } if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } } // 自己尝试加载 // 能走到这里，肯定是BootStrap没加载到，之后还有两种情况： // 1、如果delegate为ture的话，说明上层类加载器也没记载到。 // 2、如果delegate为false，那么就还没有进行过委派，先在这里尝试自己加载。 if (log.isDebugEnabled()) { log.debug(" Searching local repositories"); } try { clazz = findClass(name); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Loading class from local repository"); } if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } // 如果delegate为false,说明还没有做过委派，那么委派给父类加载器加载类。 if (!delegateLoad) { if (log.isDebugEnabled()) { log.debug(" Delegating to parent classloader at end: " + parent); } try { clazz = Class.forName(name, false, parent); if (clazz != null) { if (log.isDebugEnabled()) { log.debug(" Loading class from parent"); } if (resolve) { resolveClass(clazz); } return clazz; } } catch (ClassNotFoundException e) { // Ignore } } } throw new ClassNotFoundException(name); } 整个代码的过程就是： ...

典型回答 关于Tomcat的IO模型，不同的版本中是不太一样的，下面是一张Tomcat官网中各个历史重要版本所采用IO模型的介绍： 综合来说就是Tomcat支持多种IO模型，包括了标准的BIO（Blocking I/O）、NIO（Non-Blocking I/O）、NIO2（即JDK 1.7中的AIO）和APR（Apache Portable Runtime）。 BIO是最传统的线程模型，也称为阻塞I/O。在BIO模型中，每个客户端连接都由一个独立的线程处理。当有新的连接到来时，Tomcat会创建一个新的线程来处理请求。这意味着每个连接都需要一个独立的线程，当并发连接数较大时，会导致线程数急剧增加，占用大量系统资源，并且可能出现线程切换带来的开销。 NIO是Java的新I/O库（java.nio）的线程模型。在NIO模型中，通过使用Java NIO的选择器（Selector）机制，一个线程可以同时处理多个连接的请求。NIO模型相对于BIO模型来说，能够支持更多的并发连接，并且在连接数较大时对系统资源的消耗较少，但由于在应用层需要处理I/O事件，编程较为复杂。 NIO2是Java 7引入的进一步改进的NIO模型，也叫AIO。在NIO2中，Java提供了更多的异步I/O操作，包括异步文件I/O、异步套接字I/O等。这使得Tomcat能够更好地支持异步请求处理，提高了处理性能和效率。 APR是Apache软件基金会提供的一个库，它为应用程序提供了跨平台的抽象层，提供了高性能的本地I/O支持。在APR模型中，Tomcat利用本地操作系统的特性进行I/O操作，包括网络和文件I/O。APR模型在性能方面表现得非常出色，特别是在处理大量并发连接时，因为它直接利用底层操作系统的异步I/O能力。 我们可以在Tomcat启动的时候，可以通过log看到Connector使用的是哪一种运行模式： 1 2 3 Starting ProtocolHandler [“http-bio-8080”] Starting ProtocolHandler [“http-nio-8080”] Starting ProtocolHandler [“http-apr-8080”] 扩展知识 如何切换 切换Tomcat使用的I/O模型通常涉及配置Tomcat的连接器（Connector）。不同的I/O模型对应着不同的连接器实现。 在server.xml文件中，通过配置Connecter来选择不同的IO模型，如： 1 2 3 <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> 这里的protocol就是可以修改来替换成其他的协议，即IO模型的地方。 各个IO模型对应的关系如下： BIO模型：将protocol属性设置为HTTP/1.1（默认值），或者可以显式地设置为org.apache.coyote.http11.Http11Protocol。 NIO模型：将protocol属性设置为org.apache.coyote.http11.Http11NioProtocol。 NIO2模型：将protocol属性设置为org.apache.coyote.http11.Http11Nio2Protocol。 APR模型：将protocol属性设置为org.apache.coyote.http11.Http11AprProtocol。 但是记得修改后需要重启tomcat才会生效。而且需要注意，Tomcat的不同版本可能支持不同的I/O模型，因此请根据您使用的Tomcat版本进行相应的配置。 一般来说，建议使用NIO或者NIO2就行了，对于涉及大量I/O操作的应用，例如Web服务、聊天应用或在线游戏等，NIO或NIO2模型都挺合适。 如果对性能要求非常高，可以考虑使用APR模型，但需要安装和配置APR库，有一定的成本。

典型回答 一般这个问题，主要是因为在SpringMVC的应用中，过滤器和拦截器都是用来对请求进行预处理、过滤、拦截的，所以经常会放在一起比较。不过他们其实还有一些区别的。 他们的主要区别在于作用和生效的位置不同，过滤器是在请求进入Servlet容器之前拦截请求并对请求进行处理，而拦截器是在请求进入Servlet容器之后，但在进入Controller之前拦截请求并对请求进行处理，也可以在响应返回客户端之前，拦截响应并对响应进行处理。 在Tomcat中，一次请求会先进入到Tomcat容器，然后经过Filter的处理，处理通过之后才会进入到Servlet容器，进入到Servlet容器之后，才会在Servlet执行的前后执行Intercepter。 过滤器在请求进入Servlet容器之前拦截请求并对请求进行处理，比如对请求进行安全验证、日志记录等，之后将请求转发给对应的Servlet进行处理。过滤器是基于Java Servlet规范实现的，可以通过配置web.xml文件进行实现。 拦截器是在请求进入Servlet容器之后，拦截请求并对请求进行处理，也可以在响应返回客户端之前，拦截响应并对响应进行处理。拦截器可以对请求进行更加精细的控制，例如进行AOP、权限控制、事务管理等操作。拦截器是基于Spring框架实现的，可以通过定义拦截器类实现。 扩展知识 代码实现 定义一个过滤器，需要实现javax.servlet.Filter接口： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 public class LoginFilter implements Filter { public void init(FilterConfig config) throws ServletException { // 初始化 } public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws ServletException, IOException { // 登录验证和处理 chain.doFilter(req, resp); } public void destroy() { // 销毁 } } 并且需要在web.xml文件中把他配置上: ...

典型回答 Tomcat是一个基于Servlet规范实现的Java Web容器，所以，在接收并处理请求的过程中，Servlet是必不可少的。 主要大致流程可以分为以下几步： 1、接收请求 2、请求解析 3、Servlet查找 4、Servlet请求处理 5、请求返回 接收请求：Tomcat通过连接器监听指定的端口和协议，接收来自客户端的HTTP请求 请求解析：接收到请求之后，Tomcat首先会解析请求信息，包括请求方法、URL、请求头参数等 Servlet查找：根据解析出来的URL，找到对应的Servlet，并把请求交给他进行处理 Servlet处理：这个过程就把请求交给Servlet进行处理，主要是执行其中的service方法进行请求处理 请求返回：在Servlet处理结束后，把请求的响应在发送给客户端 扩展知识 Servlet的生命周期 Servlet在处理请求的过程中，要经历一个完整的生命周期，主要包含了以下三个阶段，分别执行三个方法，init、service和destory。每一次请求至少要经过service方法的执行，而init和destory并不需要每一个请求都执行。 初始化阶段：当Servlet容器加载Servlet时，会创建一个Servlet实例，并调用其init()方法进行初始化。在init()方法中，可以执行一些初始化操作，例如读取配置文件、连接数据库等。 处理请求阶段：在Servlet初始化完成后，当有客户端请求到达时，Servlet容器会创建一个请求对象（HttpServletRequest）和响应对象（HttpServletResponse），并调用Servlet的service()方法来处理请求。在service()方法中，Servlet可以通过请求对象获取客户端请求的信息，然后根据请求内容生成响应结果。 销毁阶段：当Servlet容器关闭或Web应用程序卸载时，会调用Servlet的destroy()方法进行销毁。在destroy()方法中，可以执行一些清理操作，例如关闭连接、释放资源等。

典型回答 在实际应用中，设置线程池的核心线程数需要综合考虑多个因素，包括系统的硬件资源、应用的业务场景、应用线程的执行时间等等。因此，线程池核心线程数的推荐值仅仅是一个基础的参考值。 对于Tomcat而言，默认最大线程数是200，默认最小空闲线程数（核心线程数）是10。 注意，这里说的是最大线程数是200，并不是核心线程数是200，而很多人说线程池建议2N或者N+1，指的也是核心线程数。 我认为，这些值应该是经过Tomcat开发团队反复测试和验证的结果，是适合绝大多数场景的。 我们作为使用者，大致可以猜测一下，Tomcat可以设置为200，可能有以下原因： Tomcat作为Web服务器，其主要的场景是处理短连接请求。相较于其他应用服务器，Tomcat的请求处理时间相对较短，因此每条请求都不会占用时间太长。 Tomcat处理的是I/O密集型任务，而不是CPU密集型任务。线程数设置为200是为了在等待I/O（如数据库查询、网络调用）时，能有足够的线程去服务新的请求，从而最大限度地利用CPU资源。 Tomcat作为Web服务器，与一般的应用程序不同，它需要处理大量的并发请求。因此，默认线程数设置的大一些，可以满足大多数Web应用的需求。 在Tomcat的默认线程池中，使用了多个优化策略，如可回收线程、无锁化算法等，这些策略可以有效地减少线程创建和销毁的开销，提高线程池的吞吐量和性能。 Tomcat的设计目标是高吞吐量和低延迟，不遵守线程池核心线程数推荐公式，是因为其默认线程池的设置已经经过充分的优化和测试，能够满足大多数的应用场景。 其实在实际工作中，我们也建议大家不要完全按照公式配置，而是根据你的实际业务情况进行充分压测之后，进行合理的配置。