Tomcat的配置文件主要包括server.xml和web.xml，它们位于Tomcat安装目录下的conf文件夹中。今天的内容重点介绍 server.xml 文件的配置，V 哥会结合一些业务场景来介绍，希望可以帮助到你，以下是一些关键的配置项及其作用：server.xml中的配置项：<Server>: 根元素，定义了Tomcat服务器的配置。port: 用于设置Tomcat服务器的端口，默认是8005。<Service>: 定义服务的元素，包含一个或多个<Connector>和<Engine>。name: 服务的名称。port: 服务监听的端口。<Connector>: 定义HTTP连接的配置。port: HTTP连接的端口，默认是8080。protocol: 连接使用的协议，如HTTP/1.1。redirectPort: 当使用SSL时，非SSL请求被重定向到的端口。<Engine>: 定义引擎的配置，引擎是Tomcat的组件，用于路由请求到相应的<Host>。defaultHost: 默认主机名。<Host>: 定义虚拟主机的配置。name: 虚拟主机的名称，可以是域名或IP地址。appBase: 应用程序的基础目录。unpackWAR: 是否解压WAR文件。<Context>: 定义Web应用程序的上下文配置。path: Web应用程序的路径。docBase: Web应用程序的基础目录或WAR文件的路径。reloadable: 是否允许重新加载应用程序。<Listener>: 定义服务器监听器，用于执行启动和停止操作。<Realm>: 定义安全域，用于认证和授权。<Valve>: 定义请求处理过程中的阀门，可以拦截或处理请求。1. <server><Server>元素是Tomcat配置文件server.xml中的根元素，它包含了整个Tomcat服务器的配置信息。以下是一些具体的业务场景和相应的<Server>配置示例：场景1：开发环境在开发环境中，我们通常希望Tomcat服务器能够快速重启以便于开发和测试。因此，可以配置较短的JVM暂停时间，以便在发生错误时快速响应。<Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" /> <Listener className="org.apache.catalina.startup.ContextConfig" /> <Listener className="org.apache.catalina.startup.UserDataConfig" /> <GlobalNamingResources> <!-- 配置资源 --> </GlobalNamingResources> </Server> 场景2：生产环境在生产环境中，稳定性和安全性是首要考虑的因素。因此，可能需要配置更长的JVM暂停时间来减少重启次数，同时配置SSL证书以支持HTTPS。<Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> <!-- 其他监听器配置 --> <GlobalNamingResources> <!-- 配置SSL证书 --> <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> </GlobalNamingResources> <!-- 配置SSL连接器 --> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" scheme="https" secure="true" SSLEnabled="true" keystoreFile="/path/to/keystore.jks" keystorePass="password" /> </Server> 场景3：负载均衡如果Tomcat服务器作为负载均衡集群的一部分，可能需要配置特定的端口用于集群通信，例如使用Tomcat的集群部署协议。<Server port="8005" shutdown="SHUTDOWN"> <!-- 配置集群监听器 --> <Listener className="org.apache.catalina.ha.session.JvmRouteBinderListener" /> <GlobalNamingResources> <!-- 配置集群相关资源 --> </GlobalNamingResources> <!-- 配置服务和引擎 --> <Service name="CatalinaCluster"> <Engine name="clusterEngine" defaultHost="localhost" jvmRoute="jvm1"> <!-- 配置Connector和Host --> </Engine> </Service> </Server> 场景4：多实例部署在需要在同一台服务器上部署多个Tomcat实例的场景中，可以为每个实例配置不同的<Server>端口。<Server port="8006" shutdown="SHUTDOWN"> <!-- 配置第一个Tomcat实例的监听器和资源 --> </Server> <Server port="8007" shutdown="SHUTDOWN"> <!-- 配置第二个Tomcat实例的监听器和资源 --> </Server> 2. <Service><Service>元素在Tomcat的server.xml配置文件中定义了一个服务，它将一个或多个连接器(<Connector>)与一个引擎(<Engine>)关联起来。以下是根据不同业务场景的<Service>配置示例：场景1：单实例应用对于大多数基本应用，您可能只需要一个服务实例来处理所有的HTTP请求。以下是一个基本的<Service>配置：<Service name="Catalina"> <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> <Engine name="Catalina" defaultHost="localhost"> <!-- 其他配置，如Host等 --> </Engine> </Service> 场景2：支持SSL的HTTPS服务如果您的应用需要通过HTTPS提供安全连接，您需要配置一个支持SSL的<Connector>：<Service name="Catalina"> <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" SSLEnabled="true" keystoreFile="/path/to/your.keystore" keystorePass="your_keystore_password" scheme="https" secure="true" /> <Engine name="Catalina" defaultHost="localhost"> <!-- 其他配置 --> </Engine> </Service> 场景3：负载均衡在负载均衡场景中，您可能需要多个服务实例来处理请求。每个服务可以绑定到不同的端口，并配置为处理不同类型的请求：<Service name="CatalinaCluster"> <Connector port="8080" protocol="HTTP/1.1" redirectPort="8443" /> <Engine name="Catalina" defaultHost="loadbalancer" jvmRoute="node1"> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" /> <Host name="loadbalancer" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 负载均衡器的配置 --> </Host> </Engine> </Service> 场景4：多个Web应用如果您需要在同一台服务器上运行多个Web应用，可以为每个应用配置不同的<Service>：<Service name="Catalina1"> <Connector port="8081" protocol="HTTP/1.1" /> <Engine name="Catalina1" defaultHost="app1.example.com"> <Host name="app1.example.com" appBase="webapp1" unpackWARs="true" autoDeploy="true"> <!-- 应用1的配置 --> </Host> </Engine> </Service> <Service name="Catalina2"> <Connector port="8082" protocol="HTTP/1.1" /> <Engine name="Catalina2" defaultHost="app2.example.com"> <Host name="app2.example.com" appBase="webapp2" unpackWARs="true" autoDeploy="true"> <!-- 应用2的配置 --> </Host> </Engine> </Service> 场景5：高可用性配置在需要高可用性的业务场景中，可以配置多个服务实例，每个实例运行在不同的端口上，并通过集群管理器进行管理：<Service name="CatalinaHA"> <Connector port="8080" protocol="HTTP/1.1" redirectPort="8443" /> <Engine name="Catalina" defaultHost="app.example.com" jvmRoute="node1"> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"> <Channel className="org.apache.catalina.ha.tcp.ReplicationChannel"> <Member className="org.apache.catalina.ha.tcp.ReplicationMember" host="node2" port="4000" /> </Channel> </Cluster> <Host name="app.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 高可用性应用的配置 --> </Host> </Engine> </Service> 3. <Connector><Connector>元素在Tomcat的server.xml配置文件中定义了服务器的网络连接参数，它用于处理客户端的HTTP请求。以下是根据不同业务场景的<Connector>配置示例：场景1：HTTP服务对于基本的HTTP服务，您需要配置一个标准的HTTP连接器：<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> port: 设置HTTP服务监听的端口。protocol: 指定使用的协议，这里使用Tomcat的HTTP/1.1处理器。connectionTimeout: 请求超时时间（毫秒）。redirectPort: 当客户端使用HTTP请求时，重定向到的HTTPS端口。场景2：HTTPS服务如果您的应用需要通过HTTPS提供加密连接，您需要配置一个支持SSL的连接器：<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" scheme="https" secure="true" SSLEnabled="true" keystoreFile="conf/keystore.jks" keystorePass="changeit" /> scheme: 设置为https表示使用安全的连接。secure: 设置为true表示请求需要安全连接。SSLEnabled: 设置为true以启用SSL。keystoreFile: 指定包含SSL证书的密钥库文件路径。keystorePass: 密钥库的密码。场景3：性能优化对于需要处理大量并发请求的应用，可以配置NIO（非阻塞I/O）或NIO2的连接器来提高性能：<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" maxThreads="150" minSpareThreads="25" acceptCount="100" /> maxThreads: 最大工作线程数。minSpareThreads: 保持运行的最小空闲线程数。acceptCount: 可以接受的请求队列长度。场景4：限制请求大小为了防止服务器被大文件上传拖慢，可以限制请求的最大大小：<Connector port="8080" protocol="HTTP/1.1" maxPostSize="20971520" /> maxPostSize: 最大POST请求大小，这里设置为20MB。场景5：启用GZIP压缩为了减少网络传输的数据量，可以配置连接器以启用GZIP压缩：<Connector port="8080" protocol="HTTP/1.1" compression="on" compressionMinSize="2048" noCompressionUserAgent="gozilla, traviata" /> compression: 设置为on以启用压缩。compressionMinSize: 启用压缩的请求最小大小（字节）。noCompressionUserAgent: 不应用压缩的浏览器列表。场景6：配置代理设置如果您的Tomcat服务器位于一个或多个代理之后，您可能需要配置连接器以正确处理请求头：<Connector port="8080" protocol="HTTP/1.1" proxyName="www.example.com" proxyPort="80" scheme="http" secure="false" /> proxyName: 代理服务器的主机名。proxyPort: 代理服务器监听的端口。4. <Engine><Engine>元素在Tomcat的server.xml配置文件中代表了一个请求引擎，它负责接收<Service>中的<Connector>转发的请求，并将请求路由到相应的<Host>或<Context>。以下是根据不同业务场景的<Engine>配置示例：场景1：基本Web应用路由对于基本的Web应用部署，您可能只需要将请求路由到默认的虚拟主机：<Engine name="Catalina" defaultHost="localhost"> <Realm className="org.apache.catalina.realm.LockOutRealm" /> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 可以包含具体的<Context>元素定义 --> </Host> </Engine> name: 引擎的名称，通常与<Service>元素的名称相匹配。defaultHost: 请求无法匹配到任何<Host>时使用的默认主机名。场景2：部署多个虚拟主机如果您需要在同一台服务器上部署多个虚拟主机，可以在同一个<Engine>下配置多个<Host>：<Engine name="Catalina" defaultHost="default"> <Host name="app1.example.com" appBase="webapps/app1" unpackWARs="true" autoDeploy="true"> <!-- 应用1的配置 --> </Host> <Host name="app2.example.com" appBase="webapps/app2" unpackWARs="true" autoDeploy="true"> <!-- 应用2的配置 --> </Host> </Engine> 场景3：集群部署在需要高可用性的集群部署场景中，可以配置集群管理器来同步会话信息：<Engine name="Catalina" defaultHost="localhost" jvmRoute="node1"> <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"> <Channel className="org.apache.catalina.ha.tcp.ReplicationChannel"> <Member className="org.apache.catalina.ha.tcp.ReplicationMember" host="node2" port="4000" /> </Channel> </Cluster> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 主机配置 --> </Host> </Engine> jvmRoute: 当前实例的JVM路由标识，用于集群中的会话查找。场景4：自定义请求过滤器如果您需要对所有请求应用自定义过滤器，可以在<Engine>下配置<Valve>：<Engine name="Catalina" defaultHost="localhost"> <Valve className="com.example.MyCustomRequestFilter" /> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 主机配置 --> </Host> </Engine> className: 指定自定义过滤器的完整类名。场景5：访问日志配置为了记录所有请求的访问日志，可以在<Engine>下配置访问日志阀：<Engine name="Catalina" defaultHost="localhost"> <Realm className="org.apache.catalina.realm.LockOutRealm" /> <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 主机配置 --> </Host> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="access_log." suffix=".txt" pattern="common" rotate="true" /> </Engine> directory: 访问日志文件存储的目录。prefix和suffix: 日志文件的前缀和后缀。pattern: 日志记录的格式。rotate: 是否启用日志轮转。5. <Host><Host>元素在Tomcat的server.xml配置文件中配置了一个虚拟主机，它处理指向特定主机名或IP地址的请求。以下是根据不同业务场景的<Host>配置示例：场景1：单个应用的虚拟主机对于单个应用的部署，您可以配置一个虚拟主机，所有请求都会映射到这个应用：<Host name="myapp.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <!-- 应用的Context配置可以在这里添加，或者在单独的XML文件中配置 --> </Host> name: 虚拟主机的名称，通常是应用的域名。场景2：多个应用的虚拟主机如果您希望一个虚拟主机管理多个应用，可以在<Host>下配置多个<Context>：<Host name="multiapp.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Context path="/app1" docBase="app1" /> <Context path="/app2" docBase="app2" /> <!-- 更多应用的Context配置 --> </Host> path: Web应用的路径。docBase: Web应用的文档基础路径或WAR文件名。场景3：使用外部定义的Context在复杂的部署场景中，您可能希望将<Context>配置在外部XML文件中，以保持server.xml的清晰：<Host name="externalctx.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Context path="" docBase="external" reloadable="true" /> <!-- 其他Context配置 --> </Host> <Context>的path可以留空，表示应用的根路径。docBase可以指向包含context.xml文件的目录。场景4：配置别名如果您希望虚拟主机响应多个域名，可以使用<Alias>元素：<Host name="alias.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Alias>www.alias.com</Alias> <!-- 应用的Context配置 --> </Host> <Alias>: 虚拟主机的另一个域名。场景5：配置SSL对于需要SSL加密的虚拟主机，可以配置一个SSL连接器，并在<Host>中指定SSL相关属性：<Host name="secure.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true" sslProtocol="TLS" sslCertificateFile="/path/to/certificate.cer" sslCertificateKeyFile="/path/to/key.key" sslPort="8443"> <!-- 应用的Context配置 --> </Host> sslProtocol: 使用的SSL协议。sslCertificateFile和sslCertificateKeyFile: SSL证书和私钥文件的路径。sslPort: SSL端口，当客户端通过这个端口访问时，将使用SSL。场景6：禁用某些HTTP方法出于安全考虑，您可能希望禁用某些HTTP方法：<Host name="securemethods.example.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Valve className="org.apache.catalina.valves.AccessLogValve" pattern="%h %l %u %t &quot;%r&quot; %s %b" /> <Context> <Valve className="org.apache.catalina.valves.MethodDisablerValve" methods="TRACE" /> </Context> </Host> methods: 需要禁用的HTTP方法列表。6. <Context><Context>元素在Tomcat的server.xml配置文件中定义了Web应用程序的上下文。每个<Context>代表一个Web应用，包括它的路径、文档基础、会话管理和其他特定于应用的设置。以下是根据不同业务场景的<Context>配置示例：场景1：基本Web应用部署对于基本的Web应用部署，您需要指定应用的路径和文档基础：<Context path="/myapp" docBase="myapp" /> path: Web应用的URL路径。docBase: Web应用的目录或WAR文件的名称。场景2：配置外部WAR文件如果您有一个外部WAR文件，希望部署为特定的上下文路径：<Context path="/externalapp" docBase="/path/to/externalapp.war" /> docBase: 指向外部WAR文件的绝对路径。场景3：使用相对路径的WAR文件在某些情况下，您可能希望使用相对于appBase的相对路径：<Context path="/relapp" docBase="webapps/relapp.war" /> 场景4：配置会话超时为了管理会话的生命周期，您可以设置会话超时时间（以分钟为单位）：<Context path="/myapp" docBase="myapp" sessionTimeout="30" /> 场景5：启用应用的重新加载在开发过程中，您可能希望在代码更改后自动重新加载应用：<Context path="/devapp" docBase="devapp" reloadable="true" /> reloadable: 设置为true以启用应用的自动重新加载。场景6：配置资源链接如果您的应用需要连接到外部资源（如数据库），您可以配置资源链接：<Context path="/myapp" docBase="myapp"> <ResourceLink global="jdbc/myDB" type="javax.sql.DataSource" name="jdbc/myAppDB" /> </Context> ResourceLink: 定义了一个资源链接，允许应用访问在<GlobalNamingResources>中定义的资源。场景7：配置安全设置对于需要安全认证的应用，您可以配置安全约束和角色：<Context path="/secapp" docBase="secapp"> <SecurityConstraint> <WebResourceCollection urlPattern="/*"> <HttpMethod constraint="POST,PUT" /> </WebResourceCollection> <AuthConstraint> < Role name="admin" /> </AuthConstraint> </SecurityConstraint> <Valve className="org.apache.catalina.authenticator.BasicAuthenticator" /> </Context> SecurityConstraint: 定义了哪些资源需要安全保护。WebResourceCollection: 定义了受保护的URL模式和HTTP方法。AuthConstraint: 定义了允许访问的的角色。Valve: 指定了认证的类型（例如，基本认证）。场景8：配置字符集和本地化为了确保应用正确处理国际化内容，您可以配置字符集和本地化：<Context path="/globalapp" docBase="globalapp" useHttpOnly="true"> <LocaleConfig defaultLocale="en" /> <CharsetConfig> <Charset name="UTF-8" /> </CharsetConfig> </Context> useHttpOnly: 设置为true以启用HttpOnly Cookies。LocaleConfig: 定义了默认地区设置。CharsetConfig: 定义了应用使用的字符集。7. <Listener><Listener>元素在Tomcat的server.xml配置文件中用于注册事件监听器，这些监听器在Tomcat的生命周期事件（如启动和停止）发生时被调用。以下是根据不同业务场景的<Listener>配置示例：场景1：自定义上下文初始化如果您需要在Tomcat启动时执行自定义逻辑，比如初始化数据库连接池或加载应用程序特定的资源，可以定义一个自定义的上下文监听器：<Listener className="com.example.MyContextListener" /> className: 指定自定义监听器的完整类名。场景2：SSL证书管理在需要动态加载或刷新SSL证书的业务场景中，可以使用自定义的证书管理监听器：<Listener className="com.example.SSLCertLoader" /> 场景3：集群会话管理当Tomcat配置为集群模式时，可以使用特定的监听器来管理会话复制：<Listener className="org.apache.catalina.ha.session.JvmRouteBinderListener" /> 这个监听器是Tomcat集群会话管理的一部分，用于设置JVM路由。场景4：请求日志记录为了记录所有进入Tomcat的请求，可以配置请求日志监听器：<Listener className="org.apache.catalina.core.AsyncListenerWrapper" /> <Listener className="org.apache.catalina.core.AprLifecycleListener" /> <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" /> <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> <Listener className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="access_log" suffix=".txt" pattern="common" resolveHosts="false" /> AccessLogValve: 用于记录访问日志的监听器，可以设置日志的目录、前缀、后缀和日志模式。场景5：性能监控为了监控Tomcat的性能，可以添加性能监控监听器：<Listener className="com.example.PerformanceMonitor" /> 场景6：Tomcat资源管理Tomcat的资源管理监听器可以用于跟踪和管理JNDI资源：<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /> 场景7：自定义用户数据管理如果您需要在Tomcat启动或停止时加载或保存用户数据，可以定义一个自定义的用户数据管理监听器：<Listener className="com.example.UserDataManager" /> 场景8：Tomcat安全监听器Tomcat提供了一些内置的安全监听器，用于在启动和停止时进行安全相关的初始化和清理：<Listener className="org.apache.catalina.authenticator.AuthenticatorBase" /> 8. <Realm><Realm>元素在Tomcat的server.xml配置文件中定义了安全域，它负责处理用户认证和授权。以下是根据不同业务场景的<Realm>配置示例：场景1：使用内存认证在开发环境中，您可能希望使用内存中的用户和角色列表进行认证：<Realm className="org.apache.catalina.realm.MemoryRealm" /> 场景2：使用JDBC数据库认证对于生产环境，您可能需要使用数据库存储用户信息和角色信息：<Realm className="org.apache.catalina.realm.JDBCRealm" driverName="com.mysql.jdbc.Driver" connectionURL="jdbc:mysql://localhost:3306/tomcatdb" dataSourceName="java:comp/env/jdbc/tomcatDataSource" userTable="users" userCredColumn="password" userNameColumn="username" /> driverName: JDBC驱动的类名。connectionURL: 数据库连接URL。dataSourceName: JNDI资源名称，用于查找数据源。userTable: 存储用户信息的数据库表。userCredColumn: 存储密码的列。userNameColumn: 存储用户名的列。场景3：使用JAAS认证如果您的应用需要使用Java Authentication and Authorization Service (JAAS)，可以配置JAAS认证：<Realm className="org.apache.catalina.realm.JAASRealm" appName="myApp" /> appName: JAAS应用的名称。场景4：使用LDAP认证当用户信息存储在LDAP服务器时，可以使用LDAP认证：<Realm className="org.apache.catalina.realm.JNDIRealm" userPattern="uid={0},ou=people,dc=example,dc=com" connectionName="uid=admin,ou=people,dc=example,dc=com" connectionPassword="adminpassword" url="ldap://ldap.example.com:389/" /> userPattern: LDAP中用户信息的搜索模式。connectionName: 连接LDAP服务器的用户名。connectionPassword: 连接LDAP服务器的密码。url: LDAP服务器的URL。场景5：使用自定义Realm如果您有特殊的认证需求，可以创建自定义的Realm实现：<Realm className="com.example.MyCustomRealm" /> 场景6：结合多个Realm使用在某些业务场景中，您可能需要结合多个Realm进行认证，例如，首先尝试使用内存认证，如果失败再尝试使用数据库认证：<Realm className="org.apache.catalina.realm.CombinedRealm"> <Realm className="org.apache.catalina.realm.MemoryRealm" /> <Realm className="org.apache.catalina.realm.JDBCRealm" driverName="..." connectionURL="..." userTable="..." userCredColumn="..." userNameColumn="..." /> </Realm> CombinedRealm: 组合多个Realm的认证器。场景7：使用容器管理的Realm如果您使用Tomcat在应用服务器（如GlassFish或JBoss）中，可能需要使用容器管理的Realm：<Realm className="org.apache.catalina.realm.ContainerRealm" ignoreEmptyPassword="true" /> ignoreEmptyPassword: 是否忽略空密码。9. <Valve><Valve>元素在Tomcat的server.xml配置文件中用于插入自定义的处理逻辑，这些处理逻辑可以在请求处理管道的不同阶段执行。以下是根据不同业务场景的<Valve>配置示例：场景1：访问日志记录记录每个请求的详细日志信息，这对于分析流量和调试应用非常有用：<Valve className="org.apache.catalina.valves.AccessLogValve" pattern="%h %l %u %t &quot;%r&quot; %s %b" /> pattern: 定义日志的格式，%h, %l, %u, %t, %r, %s, %b 分别代表主机名、登录名、用户ID、时间、请求行、状态码和字节数。场景2：请求响应时间记录监控每个请求的响应时间，以评估应用性能：<Valve className="org.apache.catalina.valves.RequestDumpValve" /> 场景3：请求过滤过滤特定的请求，例如禁用或限制某些HTTP方法：<Valve className="org.apache.catalina.valves.MethodDisablerValve" methods="TRACE" /> methods: 指定要禁用的HTTP方法列表。场景4：静态资源缓存为静态资源设置缓存头，以提高响应速度和减少服务器负载：<Valve className="org.apache.catalina.valves.StaticResourcesValve" cache="maxSize=100000,ttl=3600" /> cache: 定义缓存的大小和时间（TTL）。场景5：SSL认证强制所有请求都使用SSL连接，增强应用安全性：<Valve className="org.apache.catalina.valves.SSLValve" keystoreFile="/path/to/keystore.jks" keystorePass="password" /> keystoreFile: 密钥库文件的路径。keystorePass: 密钥库的密码。场景6：请求重写根据特定规则重写请求URI，用于URL重定向或重写：<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> XML 复制 全屏场景7：自定义请求处理执行自定义的请求处理逻辑，例如用户请求的预处理或后处理：<Valve className="com.example.MyCustomRequestValve" /> 场景8：会话管理自定义会话管理逻辑，例如会话超时处理或会话持久化：<Valve className="org.apache.catalina.valves.SessionValve" /> 场景9：错误页面定制自定义错误页面的响应，例如为不同的HTTP状态码定义不同的错误页面：<Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" /> showReport: 是否显示详细的错误报告。showServerInfo: 是否显示服务器信息。转载自https://www.cnblogs.com/wgjava/p/18381701

Java Web项目启动Tomcat时可能会遇到各种错误，这些错误可能涉及到项目本身、Tomcat配置、依赖关系、Java版本等多个方面。解决这些错误需要对Tomcat和Java Web开发的相关知识有一定的了解。以下是一些常见的启动Tomcat时可能遇到的错误及其解决方案：1. 端口被占用错误：错误描述： Tomcat启动时报端口被占用错误，通常是因为8080端口已被其他应用程序占用。解决方案：找到占用8080端口的进程，并终止该进程。修改Tomcat的端口号，可以通过编辑server.xml文件中的Connector配置，将端口号修改为其他未被占用的端口。2. Context路径配置错误：错误描述： 项目的Context路径配置错误，导致Tomcat无法正确部署项目。解决方案：检查web.xml文件中的<context-root>配置，确保路径正确。确保项目的目录结构正确，WEB-INF目录、类文件目录等都在正确的位置。3. Java版本不匹配：错误描述： 使用了不兼容的Java版本，导致Tomcat启动失败。解决方案：确保Tomcat和项目都使用相同的Java版本。在catalina.sh（Linux）或catalina.bat（Windows）文件中设置JAVA_HOME环境变量，确保指定的Java路径正确。4. 缺少依赖或jar包冲突：错误描述： 项目缺少必要的依赖，或者项目中存在依赖冲突。解决方案：使用项目管理工具（如Maven、Gradle）管理依赖，确保所有的依赖被正确引入。检查WEB-INF/lib目录下的jar包，确保没有版本冲突。5. Servlet类或配置错误：错误描述： 配置的Servlet类名或Servlet配置错误。解决方案：检查web.xml文件中的Servlet配置，确保类名、URL映射等配置正确。确保Servlet类在类路径中，且正确部署。6. 数据库连接问题：错误描述： 项目启动时无法连接数据库。解决方案：检查数据库连接配置，确保数据库地址、用户名和密码正确。确保数据库服务已启动。检查数据库驱动是否正确引入。7. 内存配置问题：错误描述： 启动时报内存溢出错误。解决方案：调整Tomcat的setenv.sh（Linux）或setenv.bat（Windows）文件，增加JVM内存参数。检查项目中是否存在内存泄漏的问题，优化代码。8. SSL证书配置错误：错误描述： 使用了HTTPS，但SSL证书配置错误。解决方案：确保SSL证书正确配置。检查server.xml中SSL相关的配置项。9. 权限问题：错误描述： Tomcat无法读取项目文件或写入日志。解决方案：确保Tomcat进程有足够的权限访问项目文件。检查日志文件夹是否有写入权限。10. 缓存问题：错误描述： 之前的项目缓存导致新的更改无法生效。解决方案：清除Tomcat工作目录下的缓存，通常在/work/Catalina/localhost/目录下。重启Tomcat。11. Tomcat版本问题：错误描述： 项目使用的Tomcat版本与项目不兼容。解决方案：确保项目使用的Tomcat版本与项目要求的版本一致。更新项目配置，以适应新的Tomcat版本。12. 其他异常：错误描述： 其他未分类的异常，可能是由于特定配置或环境导致的。解决方案：查看Tomcat日志，尝试理解错误信息。在搜索引擎中输入错误信息，查找是否有相关的解决方案。

选择 tar.gz 格式还是 zip 格式的文件下载，主要取决于操作系统和个人偏好：tar.gz (pgp, sha512)：这是一种在 Unix-like 系统（如 Linux 和 macOS）中常用的压缩格式。tar是一种将多个文件合并为单个文件（归档）的工具，而gz是 gzip，用于压缩归档文件。pgp和sha512分别提供了文件的数字签名和哈希校验，用于验证下载的文件的完整性和真实性。如果你使用的是 Linux 或 macOS，通常选择tar.gz格式更方便，因为这些系统原生支持tar和gzip命令，此外 Linux 或 macOS也提供了工具来处理zip文件。zip (pgp, sha512)：zip 是一种跨平台的文件压缩格式，Windows、macOS 和 Linux 都支持。和tar.gz类似，pgp和sha512用于验证文件。如果你使用的是 Windows，通常选择zip格式更方便，因为 Windows Explorer 原生支持zip文件的压缩和解压缩。转载自https://www.cnblogs.com/qiujicai/p/18014519

获取centos日志要在 CentOS 系统中获取实时日志，可以使用 tail 命令来查看日志文件的实时输出。例如，要查看系统日志文件 messages，可以使用以下命令：tail -f /var/log/messages 此命令将显示 messages 日志文件的实时输出，并且只有在日志文件中有新内容时才会更新输出。使用 ctrlC 组合键可以终止实时查看。获取tomcat日志如果要查看其他日志文件，只需将文件名替换为所需的日志文件名即可。例如，要查看 catalina.out 日志文件，可以使用以下命令：tail -f /opt/tomcat/logs/catalina.out同样，此命令将显示 catalina.out 日志文件的实时输出，并且只有在日志文件中有新内容时才会更新输出。使用 ctrlC 组合键可以终止实时查看。除了使用 tail 命令外，还可以使用其他命令来查看实时日志，例如 less、head、grep 等。具体使用哪个命令取决于需要查看的日志文件类型和需要查找的内容。打开日志文件查看，命令：cd /opt/apache-tomcat-8.0.30/log vi catalina.out可以使用如下快捷键进行操作?exception 查找日志的报错位置:q! 退出界面

【问题来源】桂林银行【问题简要】【必填】有以下报错【问题类别】CMS接口参数问题【AICC解决方案版本】【AICC可选择版本：8.15.1】【UAP可选择版本：UAP9600 V100R005C00SPC026】【CTI可选择版本：ICD V300R008C23SPC009】【期望解决时间】尽快【问题现象描述】【必填】智能客服平台厂家反馈一直报errorMsg，导致采集的数据一会返回几十个坐席的数据，一会就返回几个坐席的数据【日志或错误截图】【可选】是cms的参数问题导致智能客服那边一直报错吗还是什么原因，或者看cms的什么log日志告警分析

【问题来源】【必填】     浙江省公安厅 【问题简要】【必填】 维护助手巡检CMS报检测失败【问题类别】【必填】 【AICC解决方案版本】【必填】  AICC 22.100 【UAP可选择版本： UAP9600 V100R005C05SPC113 】 【CTI可选择版本：ICD V300R008C20SPC005】 【期望解决时间】【选填】 尽快【问题现象描述】【必填】 维护助手巡检CMS报检测失败【日志或错误截图】【可选】巡检包：报错内容

漏洞名称：Apache Tomcat HTTP 请求走私漏洞组件名称：Apache Tomcat影响范围：10.0.0 ≤ Apache Tomcat ≤ 10.0.2610.1.0 ≤ Apache Tomcat ≤ 10.1.0-M209.0.0 ≤ Apache Tomcat ≤ 9.0.678.5.0 ≤ Apache Tomcat ≤ 8.5.82漏洞类型：权限提升利用条件：1、用户认证：不需要用户认证2、前置条件：关闭 rejectIllegalHeader 前置条件3、触发方式：远程综合评价：<综合评定利用难度>：未知。<综合评定威胁等级>：中危，能造成钓鱼攻击。组件介绍：Apache Tomcat 是美国阿帕奇（Apache）基金会的一款轻量级 Web 应用服务器。该程序实现了对Servlet 和 JavaServer Page（JSP）的支持。漏洞简介：2022 年11月1日，监测到一则 Apache Tomcat 组件存在 HTTP 请求走私漏洞的信息，漏洞编号：CVE-2022-42252，漏洞威胁等级：中危。在关闭 rejectIllegalHeader 的条件下，攻击者可利用该漏洞构造恶意 HTTP Header 在未授权的情况执行钓鱼攻击。漏洞影响范围：目前受影响的 Apache Tomcat 版本：10.0.0 ≤ Apache Tomcat ≤ 10.0.2610.1.0 ≤ Apache Tomcat ≤ 10.1.0-M209.0.0 ≤ Apache Tomcat ≤ 9.0.678.5.0 ≤ Apache Tomcat ≤ 8.5.82解决方案：如何检测组件版本Windows 系统在 Tomcat 的 bin 目录下，输入 catalina version 命令即可显示当前版本信息。Linux 系统在 bin 目录下执行 sh version.sh 命令或 ./version.sh 命令可显示当前版本信息。官方修复建议当前官方已发布最新版本，建议受影响的用户及时更新升级到最新版本。链接如下：Apache Tomcat系列10https://tomcat.apache.org/download-10.cgiApache Tomcat系列9https://tomcat.apache.org/download-90.cgiApache Tomcat系列8https://tomcat.apache.org/download-80.cgi参考链接：https://lists.apache.org/thread/zzcxzvqfdqn515zfs3dxb7n8gty589sq

【背景】CCGW出于安全性考虑，我们的CCGW默认只提供Https的接口调用方式，不建议使用http。【问题场景】此时倘若有客户需要通过http来调用我们的接口，此时我们需修改相关配置。【解决方案】方案一:与客户沟通，讲明使用http调用接口的利弊性，建议客户使用https的方式调用。方案二：在CCGW所在的后台中，配置tomcat容器中的server.xml文件（路径：/home/{用户}/tomcat/conf），文件中的http配置默认被注释掉了，放开即可。注：放开前，确认该port未被占用。

漏洞名称：Apache Tomcat 拒绝服务漏洞组件名称：Apache Tomcat影响范围：未配置 EncryptInterceptor 则全版本受影响配置 EncryptInterceptor 如下版本受影响：10.1.0-M1 ≤ Apache Tomcat ≤ 10.1.0-M1410.0.0-M1 ≤ Apache Tomcat ≤10.0.209.0.13 ≤ Apache Tomcat ≤ 9.0.628.5.38 ≤Apache Tomcat ≤8.5.78漏洞类型：拒绝服务利用条件：1、用户认证：不需要用户认证2、前置条件：开启集群配置3、触发方式：远程综合评价：<综合评定利用难度>：未知。<综合评定威胁等级>：中危，能造成拒绝服务。漏洞分析：组件介绍：Apache Tomcat 是美国阿帕奇（Apache）软件基金会的一款轻量级 Web 应用服务器，该程序实现了对Servlet 和 JavaServer Page（JSP） 的支持。漏洞简介：2022年7月2日，监测到一则 Apache Tomcat 拒绝服务漏洞的信息，漏洞编号：CVE-2022-29885，漏洞威胁等级：中危。该漏洞是由于 Tomcat 开启集群配置中存在缺陷，攻击者可利用该漏洞在未权限的情况下，构造恶意数据造成拒绝服务，最终导致目标服务器拒绝服务。影响范围：目前受影响的 Apache Tomcat 版本：未配置EncryptInterceptor则全版本受影响配置EncryptInterceptor如下版本受影响：10.1.0-M1 ≤ Apache Tomcat ≤ 10.1.0-M1410.0.0-M1 ≤ Apache Tomcat ≤10.0.209.0.13 ≤ Apache Tomcat ≤ 9.0.628.5.38 ≤ Apache Tomcat ≤8.5.78解决方案：1.如何检测组件系统版本Windows 系统在 Tomcat 的 bin 目录下，输入 catalina version 命令即可显示版本信息。Linux 系统在 bin 目录下执行如下命令：bash version.sh  可显示版本信息。2.官方修复建议当前官方已发布最新版本，建议受影响的用户及时更新升级到最新版本。链接如下：https://tomcat.apache.org/security-10.htmlhttps://tomcat.apache.org/security-9.htmlhttps://tomcat.apache.org/security-8.html

  1. 没有开tomcat服务        在浏览器的地址栏中输入localhost:8080 回车会出现如下界面         tomcat没有开服务。在cmd中输入startup.bat。不要关闭开启的tomcat窗口。        2.输入url路径错误                在浏览器中输入url显示404,可能是输入的路径不存在或输入错误路径。        3. Java JDK环境变量未设置好         在cmd输入startup.bat时，报错。        如图:        解决方案:        这个是Java jdk的环境变量名设置不规范，将jdk的路径设置变量名必须是JAVA_HOME。        找到系统变量界面，更改错误的jdk变量名。         更改完后:   修改完之后，重新打开cmd在输入startup.bat就可以正常启动了        4.重复开启服务        服务已经开启，不需要重复打开。        5.端口被占用        通过网页访问出现 Access Error错误，端口被占用        打开cmd输入指令:将占用你所指定的端口号进程删掉netstat -ano ：查看所有端口信息netstat ano | findstr "8080" ：查看端口8080占用信息tasklist :查看所有进程tasklist | findstr "1": 查看某进程taskkill /f /pid 进程号:   删除某进程号到此这篇关于安装tomcat后可能出现的问题介绍的文章就介绍到这了转载自https://www.jb51.net/article/233667.htm

1）Bootstrap ClassLoader：可以看到上图中缺少了 Extension ClassLoader，在 Tomcat 中 Extension ClassLoader 被集成到了 Bootstrap ClassLoader 里面。2）System ClassLoader 就是 Application ClassLoader：Tomcat 中的系统类加载器不会加载 CLASSPATH 环境变量的内容，而是从以下资源库构建 System 类加载器。$CATALINA_HOME/bin/bootstrap.jar，包含用于初始化Tomcat服务器的 main() 方法，以及它所依赖的类加载器实现类。$CATALINA_BASE/bin/tomcat-juli.jar 或 $CATALINA_HOME/bin/tomcat-juli.jar，日志实现类。如果 $CATALINA_BASE/bin 中存在 tomcat-juli.jar，则使用它来代替 $CATALINA_HOME/bin中的那个。$CATALINA_HOME/bin/commons-daemon.jar3）Common ClassLoader：从名字也看出来来了，主要包含一些通用的类，这些类对 Tomcat 内部类和所有 Web 应用程序都可见。该类加载器搜索的位置由 $CATALINA_BASE/conf/catalina.properties 中的 common.loader 属性定义，默认设置将按照顺序搜索以下位置。$CATALINA_BASE/lib 中未打包的类和资源$CATALINA_BASE/lib 目录下的JAR 文件$CATALINA_HOME/lib 中未打包的类和资源$CATALINA_HOME/lib 目录下的JAR文件4）WebappX ClassLoader：Tomcat 为每个部署的 Web 应用程序创建一个单独的类加载器，这样保证了不同应用之间是隔离的，类和资源对其他 Web 应用是不可见的。加载的路径如下：Web应用的 /WEB-INF/classes 目录下的所有未打包的类和资源Web应用的 /WEB-INF/lib 目录下的 JAR 文件中的类和资源

1）Bootstrap ClassLoader：可以看到上图中缺少了 Extension ClassLoader，在 Tomcat 中 Extension ClassLoader 被集成到了 Bootstrap ClassLoader 里面。2）System ClassLoader 就是 Application ClassLoader：Tomcat 中的系统类加载器不会加载 CLASSPATH 环境变量的内容，而是从以下资源库构建 System 类加载器。$CATALINA_HOME/bin/bootstrap.jar，包含用于初始化Tomcat服务器的 main() 方法，以及它所依赖的类加载器实现类。$CATALINA_BASE/bin/tomcat-juli.jar 或 $CATALINA_HOME/bin/tomcat-juli.jar，日志实现类。如果 $CATALINA_BASE/bin 中存在 tomcat-juli.jar，则使用它来代替 $CATALINA_HOME/bin中的那个。$CATALINA_HOME/bin/commons-daemon.jar3）Common ClassLoader：从名字也看出来来了，主要包含一些通用的类，这些类对 Tomcat 内部类和所有 Web 应用程序都可见。该类加载器搜索的位置由 $CATALINA_BASE/conf/catalina.properties 中的 common.loader 属性定义，默认设置将按照顺序搜索以下位置。$CATALINA_BASE/lib 中未打包的类和资源$CATALINA_BASE/lib 目录下的JAR 文件$CATALINA_HOME/lib 中未打包的类和资源$CATALINA_HOME/lib 目录下的JAR文件4）WebappX ClassLoader：Tomcat 为每个部署的 Web 应用程序创建一个单独的类加载器，这样保证了不同应用之间是隔离的，类和资源对其他 Web 应用是不可见的。加载的路径如下：Web应用的 /WEB-INF/classes 目录下的所有未打包的类和资源Web应用的 /WEB-INF/lib 目录下的 JAR 文件中的类和资源

Tomcat 的类加载过程，也就是 WebappClassLoaderBase#loadClass 的逻辑如下。1）首先本地缓存 resourceEntries，如果已经被加载过则直接返回缓存中的数据。2）检查 JVM 是否已经加载过该类，如果是则直接返回。3） 检查要加载的类是否是 Java SE 的类，如果是则使用 BootStrap 类加载器加载该类，以防止 webapp 的类覆盖了 Java SE 的类。例如你写了一个 java.lang.String 类，放在当前应用的 /WEB-INF/classes 中，如果没有此步骤的保证，那么之后项目中使用的 String 类都是你自己定义的，而不是 rt.jar 下面的，可能会导致很多隐患。4）针对委托属性 delegate 显示设置为 true、或者一些特殊的类（javax、org 包下的部分类），使用双亲委派模式加载，只有很少部分使用双亲委派模型来加载。5）尝试从本地加载类，如果步骤5中加载失败也会走到本步骤，这边打破了双亲委派模型，优先从本地进行加载。7）走到这，代表步骤6加载失败，如果之前不是使用双亲委派模式，则在这边会委托给父类加载器来尝试加载。8）走到这边代表所有的尝试都加载失败，抛出 ClassNotFoundException。

直接把Web项目放在webapps下，Tomcat会自动将其部署在server.xml文件上配置<Context>节点，设置相关的属性即可通过Catalina来进行配置:进入到conf\Catalina\localhost文件下，创建一个xml文件，该文件的名字就是站点的名字。编写XML的方式来进行设置。

一、前言前面已经讲解了快速上手SpringBoot入门程序制作的四种方式，相信各位小伙伴们已经可以熟练的使用这些方式来创建一个简单的web程序了，但是仅仅知道这些还是不够的。接下来，带大家一起了解parent、starter、引导类、以及内嵌Tomcat相关的知识！二、百度百科Spring Boot是由Pivotal团队提供的全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot致力于在蓬勃发展的快速应用开发领域(rapid application development)成为领导者。三、简化开发从百度百科中可以看出，其目的是用来简化Spring！那么到底简化在什么地方呢？让我们想想在学习SSM时，做过原始SpringMVC程序的小伙伴应该知道，写SpringMVC程序，最基础的spring-web和spring-webmvc这两个坐标是必须的，这些还不包含我们使用的json啊等等坐标，现在呢？一个坐标搞定!以前写配置类或者配置文件，然后用什么东西就要自己写加载bean这些东西，现在呢？什么都没写，照样能用。有以下优点：简化依赖配置简化常用工程相关配置内置服务器，比如Tomcat别着急，让我们慢慢来探讨探讨其中的奥秘~四、parent介绍打开创建好的springboot程序，可以看见pom.xml文件中的<parent> </parent> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.6.4</version> <relativePath/> </parent>这里的<version>2.6.4<version>就是自己使用的springboot版本，打开后可以发现其中又继承了一个坐标，引入了很多依赖<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-dependencies</artifactId> <version>2.6.4</version> </parent>再次点击打开，就可以找到其中的奥秘了。从下图我们可以发现各式各样的依赖版本号属性，下面列出依赖版本属性的局部，可以看的出来，定义了若干个技术的依赖版本号再看看下图，各式各样的的依赖坐标信息，可以看出依赖坐标定义中没有具体的依赖版本号，而是引用了第一组信息中定义的依赖版本属性值注意：上面的依赖坐标定义是出现在<dependencyManagement>标签中的，其实是对引用坐标的依赖管理，并不是实际使用的坐标。因此当我们的项目中继承了这组parent信息后，在不使用对应坐标的情况下，前面的这组定义是不会具体导入某个依赖的最后来看看使用不同的springboot版本时，其对应的pom依赖文件有什么不同。我这里对比的是springboot2.5.6版本和springboot2.6.4从图中可以清楚的看到，当我们使用不同的springboot版本时，他们的依赖版本就会不同。这也确保了，在使用springboot时，我们可以在某种程度上避免版本冲突的复杂问题，方便了程序员们的开发！五、starter介绍SpringBoot关注到开发者在实际开发时，对于依赖坐标的使用往往都有一些固定的组合方式，比如使用spring-webmvc就一定要使用spring-web。每次都要固定搭配着写，非常繁琐，而且格式固定，没有任何技术含量。​SpringBoot一看这种情况，把所有的技术使用的固定搭配格式都给开发出来，以后我们使用某个技术，就不用一次写一堆依赖了，直接用springboot做好的这个东西就好了，对于这样的固定技术搭配，SpringBoot给它起了个名字叫做starter。​starter定义了使用某种技术时对于依赖的固定搭配格式，也是一种最佳解决方案，使用starter可以帮助开发者减少依赖配置 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>比如我想开发web应用，就需要引入上面的web对应的starter依赖，并没有写SpringMVC的坐标，点击spring-boot-starter-web我们会发现在spring-boot-starter-web中又定义了若干个具体依赖的坐标通过上图我们可以细心的发现叫做spring-boot-starter-json的名字中也有starter，打开看看里面有什么？我们可以发现，这个starter中又包含了若干个坐标，其实就是使用SpringMVC开发通常都会使用到Json，使用json又离不开这里面定义的这些坐标，看来还真是方便，SpringBoot把我们开发中使用的东西能用到的都给提前做好了。仔细看完会发现，里面有一些我们没用过的。的确会出现这种过量导入的可能性，不过没关系，可以通过maven中的排除依赖剔除掉一部分。不过你不管它也没事，大不了就是过量导入呗。​到这里基本上得到了一个信息，使用starter可以帮开发者快速配置依赖关系六、starter与parent的区别朦朦胧胧中感觉starter与parent好像都是帮助我们简化配置的，但是功能又不一样：​starter是一个坐标中定了若干个坐标，以前写多个的，现在写一个，是用来减少依赖配置的书写量的​parent是定义了几百个依赖版本号，以前写依赖需要自己手工控制版本，现在由SpringBoot统一管理，这样就不存在版本冲突了，是用来减少依赖冲突的温馨提示​ SpringBoot官方给出了好多个starter的定义，方便我们使用，而且名称都是如下格式命名规则：spring-boot-starter-技术名称七、引导类介绍配置说完了，我们发现SpringBoot确实帮助我们减少了很多配置工作，下面说一下程序是如何运行的。目前程序运行的入口就是SpringBoot工程创建时自带的那个类了，带有main方法的那个类，运行这个类就可以启动SpringBoot工程的运行，我的是这个：@SpringBootApplication public class Springboot0101Application { public static void main(String[] args) { SpringApplication.run(Springboot0101Application.class, args); }写代码测试一下，先创建一个User类，把它放在容器中@Component public class User { }然后再写一个BookController类，也把它放在容器中@RestController @RequestMapping("/books") public class BookController { @GetMapping("/getBooks") public String getBooks() { System.out.println("springboot程序正在运行呢~"); return "Hello,SpringBoot is running"; } }看看我对应类的目录结构：最后写代码测试一下：@SpringBootApplication public class Springboot0101Application { public static void main(String[] args) { ConfigurableApplicationContext applicationContext = SpringApplication.run(Springboot0101Application.class, args); BookController bookBean = applicationContext.getBean(BookController.class); System.out.println("The message of bookBean : " + bookBean); User userBean = applicationContext.getBean(User.class); System.out.println("The message of userBean : " + userBean); } }运行结果：看到结果，小伙伴们不难猜想了——SpringBoot程序启动是创建了一个Spring容器对象吧？答案就是如此！Springboot0101Application这个类在SpringBoot程序中是所有功能的入口，称这个类为引导类。​作为一个引导类最典型的特征就是当前类上方声明了一个注解@SpringBootApplication点击进入@SpringBootApplication，我们可以看到：这里面有我们之前学习SSM时用到的包扫描注解，再点击进入@SpringBootConfiguration内：我们可以发现，它最终使用了@Configuration注解，所以，归根到底，我们使用的引用类，也是一个配置类。八、内嵌Tomcat1、Tomcat定义位置程序现在已经运行了，通过引导类的main方法运行了起来。但是运行java程序不应该是执行完就结束了吗？但是我们现在明显是启动了一个web服务器啊，不然网页怎么能正常访问呢？这个服务器是在哪里写的呢？认真想一想，它就在我们引入的spring-boot-starter-web场景starter中，我们打开它来看一看：这里面有一个核心的坐标，tomcat-embed-core，叫做tomcat内嵌核心。就是这个东西把tomcat功能引入到了我们的程序中。2、Tomcat运行原理再来说第二个问题，这个服务器是怎么运行的？Tomcat服务器是一款软件，而且是一款使用java语言开发的软件，既然是使用java语言开发的，运行的时候肯定符合java程序运行的原理，java程序运行靠的是什么？对象呀，一切皆对象，万物皆对象。那tomcat运行起来呢？也是对象。如果是对象，那Spring容器是用来管理对象的，这个对象能不能交给Spring容器管理呢？答案是可以的！tomcat服务器运行其实是以对象的形式在Spring容器中运行的，怪不得我们没有安装这个tomcat，而且还能用。闹了白天这东西最后是以一个对象的形式存在，保存在Spring容器中悄悄运行的。具体运行的是什么呢？其实就是上前面提到的那个tomcat内嵌核心具体内嵌核心依赖如下：<dependency> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-core</artifactId> <version>9.0.58</version> <scope>compile</scope> <exclusions> <exclusion> <artifactId>tomcat-annotations-api</artifactId> <groupId>org.apache.tomcat</groupId> </exclusion> </exclusions> </dependency>3、更换内嵌Tomcat那既然是个对象，如果把这个对象从Spring容器中去掉是不是就没有web服务器的功能呢？当然可以，通过依赖排除可以去掉这个web服务器功能。根据SpringBoot的工作机制，用什么技术，加入什么依赖就行了。我选择的是SpringBoot提供的内置服务器jetty更换代码如下： <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> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jetty</artifactId> </dependency>让我们运行一下看看是什么样的结果：输出结果是没有问题的，但是服务器就不是默认的Tomcat了，而是我选择的jetty服务器链接：https://bbs.huaweicloud.com/blogs/336909