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

Tomcat集群原理通过Nginx负载均衡进行请求转发Tomcat集群能带来什么提高服务的性能, 并发能力, 以及高可用性提供项目架构的横向扩展能力Tomcat集群产生什么问题Session登录信息存储以及读取的问题服务器定时任务并发的问题Tomcat 单服务体系架构在这个架构图中，一层Nginx，首先Nginx主要职责给Tomcat一层反向代理。比如，我们的登录的时候登录了A服务器，session信息存储到A服务器上了，假设我们使用的负载均衡策略是ip hash，那么登录信息还可以从A服务器上访问，但是这个有可能造成某些服务器压力过大，某些服务器又没有什么压力，这个时候压力过大的机器(包括网卡带宽)有可能成为瓶颈，并且请求不够分散。首先要解决Session共享的问题这时候我们使用轮询或者最小连接负载均衡策略，就导致了，第一次访问A服务器，第二次可能访问到B服务器，这个时候存储在A服务器上的session信息在B服务器上读取不到。典型负载均衡策略分析打个比方，我们有轮询，权重，地址散列，地址散列又分为原ip地址散列hash，目标ip地址散列hash，最少连接，加权最少连接，还有继续升级的很多种策略轮询：优点：实现简单，缺点：不考虑每台服务器处理能力权重：优点：考虑了服务器处理能力的不同地址散列：优点：能实现同一个用户访问同一个服务器最少连接：优点：使集群中各个服务器负载更加均匀加权最少连接：在最少连接的基础上，为每台服务器加上权值。算法为(活动连接数*256+非活动连接数)/权重，计算出来的值小的服务器优先被选择。Session管理-Session Sticky粘滞会话：对于同一个连接中的数据包，负载均衡会将其转发至后端固定的服务器进行处理。解决了我们session共享的问题，但是它有什么缺点呢？一台服务器运行的服务挂掉，或者重启，上面的 session 都没了负载均衡器成了有状态的机器，为以后实现容灾造成了羁绊Session管理-Session 复制就是每一个Tomcat都存储我们的Session，不同的tomcat之间进行拷贝复制。解决了我们session共享的问题，但是它有什么缺点呢？应用服务器间带宽问题，因为需要不断同步session数据大量用户在线时，服务器占用内存过多Session管理-基于Cookie主要用于我们将session会话如同token一般存储在我们的前端解决了我们session共享的问题，但是它有什么缺点呢？cookie 的长度限制cookie存于浏览器，安全性是一个问题Session管理-Session 服务器就是通过一个专门管理session会话的管理器服务，进行集中化存储和管理session解决了我们session共享的问题，这种方案需要思考哪些问题呢？保证 session 服务器的可用性，session服务器单点如何解决？我们在写应用时需要做调整存储session的业务逻辑打个比方，我们为了提高session server的可用性，可以继续给session server做集群Tomcat单机部署多应用解压2个tomcat, 分别命名为tomcatA和tomcatB分别设置2个tomcat的URIEncoding, 将tomcat的conf/server.xml里的port修改为两个不同端口。作者：浩宇天尚链接：https://www.jianshu.com/p/02459aefbef1来源：简书