感受：
其实我投简历的时候，都不太敢投递阿里。因为在阿里一面前已经过了字节的三次面试，投阿里的简历一直没被捞，所以以为简历就挂了。
特别感谢一面的面试官捞了我，给了我机会，同时也认可我的努力和态度。对比我的面经和其他大佬的面经，自己真的是运气好。别人8成实力，我可能8成运气。所以对我而言，我要继续加倍努力，弥补自己技术上的不足，以及与科班大佬们基础上的差距。希望自己能继续保持学习的热情，继续努力走下去。
也祝愿各位同学，都能找到自己心动的offer。
分享我在这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档
Server：服务器。Tomcat 就是一个 Server 服务器。
Service：在服务器中可以有多个 Service，只不过在我们常用的这套 Catalina 容器的Tomcat 中只包含一个 Service，在 Service 中包含连接器和容器。一个完整的 Service 才能完成对请求的接收和处理。
连接器：Coyote 是连接器具体的实现。用于与新来的请求建立连接并解析数据。因为 Tomcat 支持的 IO 模型有 NIO、NIO2、APR，而支持的应用层协议有 HTTP1.1、HTTP2、AJP。所以针对不同的 IO 模型和应用层协议请求，在一个 Service 中可以有多个连接器来适用不同的协议的IO请求。
EndPoint ：Coyote 通信端点，即通信监听的接口，是具体 Socket 接收和发送处理器，是用来实现 TCP/IP 传输协议的。
Acceptor：用于接收请求的 socket。
Executor：线程池，在接收到请求的 socket 后会从线程池中分配一条来执行后面的操作。
Processor ：Coyote 协议处理接口，是用来实现 HTTP 应用层协议的，接收 EndPoint 、容器传来的 Socket 字节流，解析成 request 或 response 对象。
ProtocolHandler：Coyote 协议接口，通过 EndPoint 和 Processor，实现针对具体协议的处理能力。
Adapter：容器只负责处理数据，对于请求协议不同的数据，容器会无法处理，所以在 ProtocolHandler 处理生成的 request 对象后，还需要将其转成 Tomcat 定义好的统一格式的 ServletRequest 对象，Adapter 就是用来进行这样的操作的。
容器： Tomcat 的核心组件， 用于处理请求并返回数据。Catalina 是其具体的实现。
Engine：表示整个 Catalina 的 Servlet 引擎，用来管理多个虚拟站点，一个 Service 最多只能有一个 Engine。但是一个 Engine 可以包含多个 Host。
Host：表示一个主机地址，或者说一个站点，一个 Host 下有可以配置多个 Context。
Context：表示一个 web 应用，一个 Web 应用可以包含多个 Wrapper
Wrapper：表示一个 Servlet，是容器中的最底层组件。
各组件的比例关系
各组件的实现与执行
=========
组件实现
====
前面提到的各个组件名都是接口或者抽象方法，在实际处理请求时执行的都是其子类或者实现类。
Server、Service、Engine、Host、Context都是接口， 下图中罗列了这些接口的默认实现类。
Adapter 的实现是 CoyoteAdapter
对于 Endpoint组件来说，在Tomcat中没有对应的Endpoint接口， 但是有一个抽象类AbstractEndpoint ，其下有三个实现类： NioEndpoint、Nio2Endpoint、AprEndpoint ， 这三个实现类，分别对应于前面讲解链接器 Coyote 时， 提到的链接器支持的三种IO模型：NIO，NIO2，APR ，tomcat8.5版本中，默认采用的是 NioEndpoint。
ProtocolHandler ： Coyote协议接口，通过封装Endpoint和Processor ， 实现针对具体协议的处理功能。Tomcat按照协议和IO提供了6个实现类。
AJP协议：
1） AjpNioProtocol ：采用NIO的IO模型。
2） AjpNio2Protocol：采用NIO2的IO模型。
3） AjpAprProtocol ：采用APR的IO模型，需要依赖于APR库。
HTTP协议：
1） Http11NioProtocol ：采用NIO的IO模型，默认使用的协议（如果服务器没有安装APR）。
2） Http11Nio2Protocol：采用NIO2的IO模型。
3） Http11AprProtocol ：采用APR的IO模型，需要依赖于APR库。
这些组件均存在初始化、启动、停止等周期方法，所以 Tomcat 设计了一个 LifeCycle 接口，用于定义这些组件生命周期中需要执行的共同方法，这些组件实现类都实现了这个接口。
启动流程
====
1） 启动tomcat ， 需要调用 bin/startup.bat (在linux 目录下 , 需要调用 bin/startup.sh) ， 在
startup.bat 脚本中, 调用了catalina.bat。
2） 在catalina.bat 脚本文件中，调用了BootStrap 中的main方法。
3）在BootStrap 的main 方法中调用了 init 方法 ， 来创建Catalina 及 初始化类加载器。
4）在BootStrap 的main 方法中调用了 load 方法 ， 在其中又调用了Catalina的load方法。
5）在Catalina 的load 方法中 , 需要进行一些初始化的工作, 并需要构造Digester 对象, 用于解析 XML。
6） 然后在调用后续组件的初始化操作 。。。
加载Tomcat的配置文件，初始化容器组件 ，监听对应的端口号， 准备接受客户端请求 。
简而言之就是进行各组件逐级执行 init() 和 start() 方法。
执行流程
====
当一个请求进入 Tomcat 时，执行情况如下( 因为 Tomcat 只有一个 Service，所以下面就将 Service 和 Engine 写在同一个框中）：
定位主要通过 Mapper 组件来实现，其本质就是一个 K、V键值对，在解析时首先会将请求网址进行解析，将其中的 Host 部分在 Mapper 类中的 hosts属性（MappedHost数组，保存所有的 Host 信息）中进行查找，找到后再解析 Context 部分，在该 MapperHost 中又有 contextList 属性（保存所有的 context 信息），然后再向下找，最终得到对应的 Servlet，执行。
除此之外，为了增强各组件之间的拓展性，Tomcat 中定义了 Pipeline 和 Valve 两个接口，Pipeline 用于构建责任链， 后者代表责任链上的每个处理器。Pipeline 中维护了一个基础的 Valve，它始终位于Pipeline的末端（最后执行），封装了具体的请求处理和输出响应的过程。当然，我们也可以调用addValve()方法， 为Pipeline 添加其他的Valve，后添加的Valve 位于基础的Valve之前，并按照添加顺序执行。Pipiline通过获得首个Valve来启动整合链条的执行 。
所以最终的执行如下：
步骤如下:
1）Connector组件Endpoint中的Acceptor监听客户端套接字连接并接收Socket。
2）将连接交给线程池Executor处理，开始执行请求响应任务。
3）Processor组件读取消息报文，解析请求行、请求体、请求头，封装成Request对象。
4）Mapper组件根据请求行的URL值和请求头的Host值匹配由哪个Host容器、Context容器、Wrapper容器处理请求。
5）CoyoteAdaptor组件负责将Connector组件和Engine容器关联起来，把生成的Request对象和响应对象Response传递到Engine容器中，调用 Pipeline。
6）Engine容器的管道开始处理，管道中包含若干个Valve、每个Valve负责部分处理逻辑。执行完Valve后会执行基础的 Valve–StandardEngineValve，负责调用Host容器的Pipeline。
7）Host容器的管道开始处理，流程类似，最后执行 Context容器的Pipeline。
8）Context容器的管道开始处理，流程类似，最后执行 Wrapper容器的Pipeline。
9）Wrapper容器的管道开始处理，流程类似，最后执行 Wrapper容器对应的Servlet对象的处理方法。
配置文件
====
首先看一下 tomcat 的目录结构
核心配置文件在 conf 目录下
Server.xml(重点)
==============
其中最重要的就是 server.xml，主要配置了 tomcat 容器的所有配置。下面来看一下其中有哪些配置。
Server
======
是 server.xml 的根元素，用于创建一个 Server 实例，默认的实现是
…
port：Tomcat监听的关闭服务器的端口
shutdown：关闭服务器的指令字符串。
Server 内嵌的子元素为 Listener、GlobalNamingResources、Service。
配置的5个Listener 的含义：
GlobalNamingResources 中定义了全局命名服务
Service
=======
用于创建 Service 实例，内嵌的元素为：Listener、Executor、Connector、Engine，其中 ： Listener 用于为Service添加生命周期监听器， Executor 用于配置Service 共享线程池，Connector 用于配置Service 包含的链接器， Engine 用于配置Service中链接器对应的Servlet 容器引擎。默认 Service 就叫 Catalina。
Executor
=========
默认情况，Service 并未配置共享线程池，各个连接器使用的都是各自的线程池（默认size为10）。如果我们想添加一个线程池，可以在 Service 标签中添加如下配置
<Executor name=“tomcatThreadPool”
namePrefix=“catalina-exec-”
maxThreads=“200”
minSpareThreads=“100”
maxIdleTime=“60000”
maxQueueSize=“Integer.MAX_VALUE”
prestartminSpareThreads=“false” threadPriority=“5”
className=“org.apache.catalina.core.StandardThreadExecutor”/>
相关属性说明：
Connector
==========
用于创建连接器实例，默认情况下，server.xml 配置了两个连接器，一个支持 HTTP 协议，一个支持 AJP 协议。
1） port： 端口号，Connector 用于创建服务端Socket 并进行监听， 以等待客户端请求链接。如果该属性设置为0，Tomcat将会随机选择一个可用的端口号给当前Connector 使用。
2） protocol ： 当前Connector 支持的访问协议。 默认为 HTTP/1.1 ， 并采用自动切换机制选择一个基于 JAVA NIO 的链接器或者基于本地APR的链接器（根据本地是否含有Tomcat的本地库判定）。如果不希望采用上述自动切换的机制， 二是明确指定协议， 可以使用以下值。
Http协议：
org.apache.coyote.http11.Http11NioProtocol ， 非阻塞式 Java NIO 链接器
org.apache.coyote.http11.Http11Nio2Protocol ， 非阻塞式 JAVA NIO2 链接器
org.apache.coyote.http11.Http11AprProtocol ， APR 链接器
AJP协议：
org.apache.coyote.ajp.AjpNioProtocol ， 非阻塞式 Java NIO 链接器
org.apache.coyote.ajp.AjpNio2Protocol ，非阻塞式 JAVA NIO2 链接器
org.apache.coyote.ajp.AjpAprProtocol ， APR 链接器
3） connectionTimeOut : Connector 接收链接后的等待超时时间， 单位为 毫秒。 -1 表示不超时。
4） redirectPort：当前Connector 不支持SSL请求， 接收到了一个请求， 并且也符合securityconstraint 约束， 需要SSL传输，Catalina自动将请求重定向到指定的端口。
5） executor ： 指定共享线程池的名称， 也可以通过maxThreads、minSpareThreads 等属性配置内部线程池。
6） URIEncoding : 用于指定编码URI的字符编码， Tomcat8.x版本默认的编码为 UTF-8 , Tomcat7.x版本默认为ISO-8859-1。
Engine
======
Engine 作为Servlet 引擎的顶级元素，内部可以嵌入： Cluster、Listener、Realm、Valve和 Host。
…
1） name： 用于指定Engine 的名称， 默认为Catalina 。该名称会影响一部分Tomcat的存储路径（如临时文件）。
2） defaultHost ： 默认使用的虚拟主机名称， 当客户端请求指向的主机无效时， 将交由默认的虚拟主机处理， 默认为localhost。 在 ip 地址解析时首先根据defaultHost 设置的 Host从 Host 列表中找对用的 Host 跳转，如果没有再从 Host 列表中查找对应的，如果列表中没有，那么就会访问不到。
除此之外，在默认的配置文件中还包含 Realn 标签，如下：
标签是用来配置用户权限的。
首先说一下 tomcat 的权限管理。因为在 tomcat 中可以配置多个 web 项目，而 tomcat 为这些项目的管理创建了管理页面，也就是默认 webapps 下 host-manager 与 manager 文件夹的项目页面，为了保证安全性，访问这两个项目需要设置权限，但是如果对每个新用户都单独的设置权限比较繁琐麻烦，所以在 tomcat 中定义了几种不同的权限，我们可以自己配置 “角色”(可以看作是特定权限的集合) 和 “用户”(设置登录名、密码，与角色相关联)，然后就可以通过自定义的 “用户” 去访问管理页面。“角色” 和 “用户” 的配置默认可以在 tomcat-users.xml 中配置。当 tomcat 启动后，就会通过 conf 目录下的 server.xml 中的 Realm 标签来检查权限。
支持多种 Realm 管理方式：
1 JDBCRealm 用户授权信息存储于某个关系型数据库中，通过JDBC驱动获取信息验证
2 DataSourceRealm 用户授权信息存储于关于型数据中，通过JNDI配置JDBC数据源的方式获取信息验证
3 JNDIRealm 用户授权信息存储在基于LDAP的目录服务的服务器中，通过JNDI驱动获取并验证
4 UserDatabaseRealm 默认的配置方式，信息存储于XML文档中 conf/tomcat-users.xml
5 MemoryRealm 用户信息存储于内存的集合中，对象集合的数据来源于xml文档 conf/tomcat-users.xml
6 JAASRealm 通过JAAS框架访问授权信息
上面代码块中可以看出Realm就是使用默认的 UserDatabaseRealm 方式配置。而它的 resourceName 就对应之前 中配置的 conf 目录下的 tomcat-users.xml 文件。
如果在Engine下配置Realm， 那么此配置将在当前Engine下的所有Host中共享。 同样，如果在Host中配置Realm ， 则在当前Host下的所有Context中共享。底层会覆盖掉上层对同一个资源的配置。
Host
====
用于配置一个虚拟主机， 它支持以下嵌入元素：Alias、Cluster、Listener、Valve、Realm、Context。一个 Engine 标签下可以配置多个 Host。
…
属性说明：
1） name: 当前Host通用的网络名称， 必须与DNS服务器上的注册信息一致。 Engine中包含的Host必须存在一个名称与Engine的defaultHost设置一致。
2） appBase： 当前Host的应用基础目录， 当前Host上部署的Web应用均在该目录下（可以是绝对目录，相对路径）。默认为webapps。
3） unpackWARs： 设置为true， Host在启动时会将appBase目录下war包解压为目录。设置为 false， Host将直接从war文件启动。
4） autoDeploy： 控制tomcat是否在运行时定期检测并自动部署新增或变更的web应用。
Context
=======
用于配置一个 Web 应用。
…
属性描述：
1） docBase：Web应用目录或者War包的部署路径。可以是绝对路径，也可以是相对于 Host appBase的相对路径。
2） path：Web应用的Context 路径。如果我们Host名为localhost， 则该web应用访问的根路径为：http://localhost:8080/myApp。它支持的内嵌元素为：CookieProcessor， Loader， Manager，Realm，Resources，WatchedResource，JarScanner，Valve。
tomcat-user.xml(权限管理)
=====================
上面的 realm 标签说到这个文件是配合 realm 标签来设置用户权限的，所以就来看一下具体是如何设置的。
首先看一下默认配置
<?xml version="1.0" encoding="UTF-8"?><tomcat-users xmlns=“http://tomcat.apache.org/xml”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=“http://tomcat.apache.org/xml tomcat-users.xsd”
version=“1.0”>
标签内有两个子标签， 和 ，role 是用来设置 “角色”，而 user 是用来设置登陆 “用户” 的。管理页面是 webapps 下的 host-manager 与 manager 目录，分别来管理所有主机以及所有的 web项目。如果我们只将注释的部分打开，还是不能访问管理页面，因为 tomcat 设置了特定的权限名，首先是 manager：
manager-gui 允许访问html接口(即URL路径为/manager/html/*)
manager-script 允许访问纯文本接口(即URL路径为/manager/text/*)
manager-jmx 允许访问JMX代理接口(即URL路径为/manager/jmxproxy/*)
manager-status 允许访问Tomcat只读状态页面(即URL路径为/manager/status/*)
对于 host-manager：
admin-gui 允许访问html接口(即URL路径为/host-manager/html/*)
admin-script 允许访问纯文本接口(即URL路径为/host-manager/text/*)
admin-jmx 允许访问JMX代理接口(即URL路径为/host-manager/jmxproxy/*)
admin-status 允许访问Tomcat只读状态页面(即URL路径为/host-manager/status/*)
如果我们想让某个角色直接能访问这两个项目页面，可以将 roles 配置成下面的设置，然后就可以访问 manager 和 host-manager 页面了。
Web.xml(不常用)
=============
web.xml 目前已经很少再用了，所以这部分内容简单了解下即可。web.xml 文件分为 tomcat 安装目录的 conf 下的以及各个项目的 WEB-INF 目录下的。conf 下的是全局配置，所有 web 项目都会受到影响，而 WEB-INF 下的只会作用于当前项目，但是如果与 conf 下的 web.xml 配置冲突，那么就会覆盖掉 conf的。
ServletContext 初始化全局参数
======================
K、V键值对。可以在应用程序中使用
javax.servlet.ServletContext.getInitParameter()方法获取参数值。
contextConfigLocation
classpath:applicationContext-*.xml
Spring Config File Location <
会话设置
=====
用于配置Web应用会话，包括 超时时间、Cookie配置以及会话追踪模式。它将覆盖server.xml 和 context.xml 中的配置。
30
JESSIONID
www.itcast.cn
Session Cookie
true
false
3600
COOKIE
1） session-timeout ： 会话超时时间，单位：分钟
2） cookie-config： 用于配置会话追踪Cookie
name：Cookie的名称
domain：Cookie的域名
path：Cookie的路径
comment：注释
http-only：cookie只能通过HTTP方式进行访问，JS无法读取或修改，此项可以增加网站访问的安全性。
secure：此cookie只能通过HTTPS连接传递到服务器，而HTTP 连接则不会传递该信息。注意是从浏览器传递到服务器，服务器端的Cookie对象不受此项影响。
max-age：以秒为单位表示cookie的生存期，默认为-1表示是会话Cookie，浏览器关闭时就会消失。
3） tracking-mode ：用于配置会话追踪模式，Servlet3.0版本中支持的追踪模式：COOKIE、URL、SSL
A. COOKIE : 通过HTTP Cookie 追踪会话是最常用的会话追踪机制， 而且Servlet规范也要求所有的Servlet规范都需要支持Cookie追踪。
B. URL : URL重写是最基本的会话追踪机制。当客户端不支持Cookie时，可以采用URL重写的方式。当采用URL追踪模式时，请求路径需要包含会话标识信息，Servlet容器会根据路径中的会话标识设置请求的会话信息。如： http：//www.myserver.com/user/index.html;jessionid=1234567890。
C. SSL : 对于SSL请求， 通过SSL会话标识确定请求会话标识。
Servlet 配置
==========
最后
为什么我不完全主张自学？
①平台上的大牛基本上都有很多年的工作经验了，你有没有想过之前行业的门槛是什么样的，现在行业门槛是什么样的？以前企业对于程序员能力要求没有这么高，甚至十多年前你只要会写个“Hello World”，你都可以入门这个行业，所以以前要入门是完全可以入门的。
②现在也有一些优秀的年轻大牛，他们或许也是自学成才，但是他们一定是具备优秀的学习能力，优秀的自我管理能力（时间管理，静心坚持等方面）以及善于发现问题并总结问题。
如果说你认为你的目标十分明确，能做到第②点所说的几个点，以目前的市场来看，你才真正的适合去自学。
除此之外，对于绝大部分人来说，报班一定是最好的一种快速成长的方式。但是有个问题，现在市场上的培训机构质量参差不齐，如果你没有找准一个好的培训班，完全是浪费精力，时间以及金钱，这个需要自己去甄别选择。
我个人建议线上比线下的性价比更高，线下培训价格基本上没2W是下不来的，线上教育现在比较成熟了，此次疫情期间，学生基本上都感受过线上的学习模式。相比线下而言，线上的优势以我的了解主要是以下几个方面：
①价格：线上的价格基本上是线下的一半；
②老师：相对而言线上教育的师资力量比线下更强大也更加丰富，资源更好协调；
③时间：学习时间相对而言更自由，不用裸辞学习，适合边学边工作，降低生活压力；
④课程：从课程内容来说，确实要比线下讲的更加深入。
应该学哪些技术才能达到企业的要求？（下图总结）
C. SSL : 对于SSL请求， 通过SSL会话标识确定请求会话标识。
Servlet 配置
==========
最后
为什么我不完全主张自学？
①平台上的大牛基本上都有很多年的工作经验了，你有没有想过之前行业的门槛是什么样的，现在行业门槛是什么样的？以前企业对于程序员能力要求没有这么高，甚至十多年前你只要会写个“Hello World”，你都可以入门这个行业，所以以前要入门是完全可以入门的。
②现在也有一些优秀的年轻大牛，他们或许也是自学成才，但是他们一定是具备优秀的学习能力，优秀的自我管理能力（时间管理，静心坚持等方面）以及善于发现问题并总结问题。
如果说你认为你的目标十分明确，能做到第②点所说的几个点，以目前的市场来看，你才真正的适合去自学。
除此之外，对于绝大部分人来说，报班一定是最好的一种快速成长的方式。但是有个问题，现在市场上的培训机构质量参差不齐，如果你没有找准一个好的培训班，完全是浪费精力，时间以及金钱，这个需要自己去甄别选择。
我个人建议线上比线下的性价比更高，线下培训价格基本上没2W是下不来的，线上教育现在比较成熟了，此次疫情期间，学生基本上都感受过线上的学习模式。相比线下而言，线上的优势以我的了解主要是以下几个方面：
①价格：线上的价格基本上是线下的一半；
②老师：相对而言线上教育的师资力量比线下更强大也更加丰富，资源更好协调；
③时间：学习时间相对而言更自由，不用裸辞学习，适合边学边工作，降低生活压力；
④课程：从课程内容来说，确实要比线下讲的更加深入。
应该学哪些技术才能达到企业的要求？（下图总结）
[外链图片转存中…(img-rqU7VaAP-1715327762954)]
[外链图片转存中…(img-9avW32ze-1715327762954)]
4571
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
