服务器面试题

服务器分类

根据服务器的用处服务器可以分很多类

web服务器

Web服务器一般指的是处理静态请求或转发http请求的服务器，主要就是http服务，包括图片的下载，等等一系列和web相关的。

静态资源服务器

web服务器作为处理静态请求使用，就是静态资源服务器，静态资源一般包括js、css、img 等，可以用nginx或cdn做

代理服务器和反向代理服务器

web服务器作为转发http请求使用，就可以分为代理服务器和反向代理服务器,

应用服务器

应用服务器一般是用来处理动态请求的服务器。大多数应用服务器也包含了Web服务器的功能，这里的应用有很多，比如java应用，ruby 应用，或者 c#应用。

 

常见的web应用服务器：tomcat,jboss,weblogic等

FTP 服务器

是在互联网上提供文件存储和访问服务的计算机，它们依照FTP协议提供服务。 FTP是File Transfer Protocol(文件传输协议)。顾名思义，就是专门用来传输文件的协议。简单地说，支持FTP协议的服务器就是FTP服务器。

数据库服务器

建立有数据库系统的，提供数据库管理的服务器

java的服务器有哪些

Java 的应用服务器分为两大类：JSP 服务器和 Java EE 服务器

JSP 服务器有 Tomcat 、 Jetty 、Bejy Tiger 、Geronimo 、Jonas 、Jrun 、Orion 、Resin。

 

Java EE 服务器有 IBM Websphere 、Weblogic、JBoss、TongWeb 、BES Application Server 、 Apusic Application Server 、Sun Application Server 、Oracle 的 Oracle9i/AS 、Sun Java System Application Server 、Weblogic 、开源GlassFish。

 

JSP服务器与Java EE服务器区别

javaee服务器提供了一些JSP服务器没有的东西，比如支持EJB等

 

tomcat相关

说一下tomcat

Tomcat是由Apache提供的开源免费Web 应用服务器。tomcat默认的端口号是8080，访问tomcat不指定项目名称默认是访问的webapps下的ROOT项目

是一个小型的轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。

 

apache tomcat=Apache http server + Tomcat

Apache http server是只支持静态页面的http服务器，tomcat只是一个servlet容器，是Apache的扩展，处理动态网页部分。

Apache http server 是由c语言开发，而Tomcat则是由java开发(所以运行tomcat需要安装jdk)

tomcat的功能是什么

接受客户端的访问

向客户端做出反应

可以把动态资源转换成静态资源，再发送给浏览器

 

tomcat目录介绍

  • bin
  • conf
  • lib
  • logs
  • temp
  • webapps
  • work

 

bin：

存放可执行文件，

启动startup.bat、startup.sh，关闭shutdown.bat、shutdown.sh,catalina.bat、catalina.sh等可执行文件都在里面，其中startup和shutdown的执行都会调用catalina可执行文件

 

conf:

存放配置文件，

server.xml：配置端口号，虚拟主机等

tomcat-users.xml：配置用户名、密码、用户角色等，用户用于登录后台管理页面

web.xml:定义了session的有效期，mime类型，欢迎页，默认的servlet(找不到匹配的url就会访问到省却的servlet)和JspServlet(访问带有jsp结尾的url会访问到该servlet)（应用的web.xml有相同配置应用中的优先级高）

context.xml：对所有应用的统一配置

 

lib:

Tomcat的类库

 

logs:

存放的日志文件：

catalina.x.log启动日志，localhost.日期.log启动日志（没有第一种全），localhost_access_log.日期.txt访问日志，manager.日期.log和host-manager.日期.log自带的manager项目的日志

 

temp：

临时文件目录，这个目录下的东西可以在关闭Tomcat后删除

 

webapps ：

存放web项目的目录，其中每个文件夹都是一个项目；当我们启动tomcat后，该目录下的所有项目都可以访问到

里面有tomcat自带的项目：docs,examples,host-manager,manager,ROOT

在地址栏中没有给出项目目录名时，对应的就是ROOT项目。

http://localhost:8080/examples，进入示例项目，其中examples就是项目名，即文件夹的名字。

ROOT项目有很多链接是访问其他的项目的

work ：

运行时生成的文件，最终运行的文件都在这里。通过webapps中的项目生成的！可以把这个目录下的内容删除，再次运行时会生再次生成work目录。当客户端用户访问一个JSP文件时，Tomcat会通过JSP生成对应的Java文件，然后再编译该Java文件生成对应的class文件，生成的java和class文件都会存放到这个目录下。

 

DefaultServlet

在tomcat的conf/web.xml设置的默认Servlet，它的映射路径为/，表示当访问的资源没有可以匹配的servlet时，会访问该Servlet,默认服务器启动时加载

该Servlet的作用是：服务于静态资源又服务于目录列表

因为有它我们才能访问到js,css，img等资源

JspServlet

在tomcat的conf/web.xml设置的该Servlet,映射路径有*.jsp,*.jspx，默认服务器启动时加载

作用：JSP页的编译和执行Servlet, 是Tomcat支持JSP页面的机制，我们直接通过一个URL例如/index.jsp来访问jsp，该servlet来处理JSP页面

 

server.xml介绍

server.xml配置了tomcat启动时要使用的配置

整体结构：

<Server>
      <Service>
          <Connector />
          <Connector />
          <Engine>
              <Host>
                  <Context />
              </Host>
          </Engine>
     </Service>
 </Server>

 

Tomcat主要组件：服务器Server，服务Service，连接器Connector、容器Container。连接器Connector和容器Container是Tomcat的核心。

server:代表整个Tomcat容器,一个Server元素中可以有一个或多个Service元素。

Service:作用是Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。有多个service时，不同的Service监听不同的端口

 

Connector标签：连接器组件

<Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

redirectPort表示当强制要求https而请求是http时，重定向至端口号为8443的Connector，connectionTimeout表示连接的超时时间。

tomcat中默认配置了两种协议的连接器：HTTP/1.1与AJP/1.3

HTTP/1.1协议负责建立HTTP连接，用于在8080端口监听浏览器的http请求；

AJP/1.3协议负责和其他HTTP服务器建立连接，监听的是8009端口，比如tomcat和apache或者iis集成时需要用到这个连接器。

当这两个组件启动时会创建监听客户端请求守护线程，其中的http-bio-8080-Acceptor-0线程当接收到http连接请求时会从工作线程池中获取线程来处理请求，并把产生的 Request 和 Response 对象传给处理Engine(Container中的一部分)，从Engine出获得响应并返回客户。

Connector 最重要的功能就是接收连接请求然后分配线程让 Container 来处理这个请求

 

Connector处理浏览器http请求的protocol的协议包括BIO、NIO和APR（Tomcat7中支持这3种，Tomcat8增加了对NIO2的支持，而到了Tomcat8.5和Tomcat9.0，则去掉了对BIO的支持）。具体值为

org.apache.coyote.http11.Http11Protocol：BIO  阻塞模型

org.apache.coyote.http11.Http11NioProtocol：NIO  非阻塞模型

org.apache.coyote.http11.Http11Nio2Protocol：NIO2  tomcat8.0后支持(也有人说AIO)

org.apache.coyote.http11.Http11AprProtocol：APR 高性能，可扩展的模式

 

HTTP/1.1：默认值，使用的协议与Tomcat版本有关 ，在Tomcat7中，自动选取使用BIO或APR（如果找到APR需要的本地库，则使用APR，否则使用BIO）；在Tomcat8中，自动选取使用NIO或APR（如果找到APR需要的本地库，则使用APR，否则使用NIO）。

 

无论是BIO，还是NIO，Connector处理请求的大致流程是一样的：

在accept队列中接收连接（当客户端向服务器发送请求时，如果客户端与OS完成三次握手建立了连接，则OS将该连接放入accept队列）；在连接中获取请求的数据，生成request；调用servlet容器处理请求；返回response。

 

在BIO实现的Connector中Acceptor线程接收到请求后会从Worker线程池中获取线程处理，之后请求结束后，如果没有新的请求到来，socket不会立马释放，而是等timeout后再释放。释放前还占用着worker中的工作线程

在NIO实现的Connector中Acceptor接收到请求后通过队列将请求发送给了Poller，在Poller中，维护了一个Selector对象；当Poller从队列中取出socket后，注册到该Selector中；然后通过遍历Selector，找出其中可读的socket，并使用Worker中的线程处理相应请求。在NIO中Acceptor接收socket使用的仍然是阻塞方式，但当socket在等待下一个请求或等待释放时，并不会占用工作线程使用的非阻塞方式。

 

BIO和NIO中的Worker是Tomcat自带的线程池可以被自定义的线程池代替。

 

Executor：tomcat线程池

如果要使用它定义在Connector元素之前，默认每个Connector都会使用独立的线程池，配置该元素可以让Connector共享这一个线程池，其他的组件也可以用；默认是没有配置该元素

<Executor name="tomcatThreadPool" namePrefix ="catalina-exec-" maxThreads="150" minSpareThreads="4" />
<Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" acceptCount="1000" />

 

 

容器：<Engine><Host><Context>

Engine、Host和Context都是容器，容器的功能是处理Connector接收进来的请求，并产生相应的响应。他们是父子关系

<Engine name="Catalina" defaultHost="localhost">

name属性用于日志和错误信息，在整个Server中应该唯一。defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。

<Host name="localhost"  appBase="webapps"unpackWARs="true" autoDeploy="true">

 

每个Host组件代表Engine中的一个虚拟主机。对应了服务器中一个网络名实体(如”www.test.com”，或IP地址”116.25.25.25”)；Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。name属性指定虚拟主机的主机名，为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。

Host虚拟主机的作用，是运行多个Web应用（一个Context代表一个Web应用），并负责安装、展开、启动和结束每个Web应用。

客户端通常使用主机名来标识它们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名，寻找名称匹配的主机。如果没有匹配，请求将发送至默认主机。因此默认主机不需要是在DNS服务器中注册的网络名，因为任何与所有Host名称不匹配的请求，都会路由至默认主机。

unpackWARs指定了是否将代表Web应用的WAR文件解压；如果为true，通过解压后的文件结构运行该Web应用，如果为false，直接使用WAR文件运行Web应用。

Host的autoDeploy和appBase属性，与Host内Web应用的自动部署有关；此外，本例中没有出现的xmlBase和deployOnStartup属性，也与Web应用的自动部署有关；

 

Context元素代表在特定虚拟主机上运行的一个Web应用。每个Host中可以定义任意多的Context元素。默认没有Context元素的配置。这是因为Tomcat开启了自动部署，Web应用没有在server.xml中配置静态部署，而是由Tomcat通过特定的规则自动部署。

Context元素最重要的属性是docBase和path，此外reloadable属性也比较常用。

docBase指定了该Web应用使用的WAR包路径，或应用目录。需要注意的是，在自动部署场景下，docBase不在appBase目录中，才需要指定；如果docBase指定的WAR包或应用目录就在appBase中，则不需要指定，因为Tomcat会自动扫描appBase中的WAR包和应用目录，path指定了访问该Web应用的上下文路径，当请求到来时，Tomcat根据Web应用的 path属性与URI的匹配程度来选择Web应用处理相应请求。例如，Web应用app1的path属性是”/app1”，Web应用app2的path属性是”/app2”，那么请求/app1/index.html会交由app1来处理；而请求/app2/index.html会交由app2来处理。如果一个Context元素的path属性为””，那么这个Context是虚拟主机的默认Web应用；当请求的uri与所有的path都不匹配时，使用该默认Web应用来处理。在自动部署场景下，不能指定path属性，path属性由配置文件的文件名、WAR文件的文件名或应用目录的名称自动推导出来。如扫描Web应用时，发现了xmlBase目录下的app1.xml，或appBase目录下的app1.WAR或app1应用目录，则该Web应用的path属性是”app1”。如果应用名称是ROOT，则该Web应用是虚拟主机默认的Web应用，此时path属性推导为””。

reloadable属性指示tomcat是否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下class文件的改动。如果值为true，那么当class文件改动时，会触发Web应用的重新加载。在开发环境下，reloadable设置为true便于调试；但是在生产环境中设置为true会给服务器带来性能压力，因此reloadable参数的默认值为false。

tomcat自动部署

要开启Web应用的自动部署，需要配置server.xml的Host元素的deployOnStartup和autoDeploy属性。

如果deployOnStartup和autoDeploy设置为true，则tomcat启动自动部署：当检测到新的Web应用或Web应用的更新时，会触发应用的部署(或重新部署)。二者的主要区别在于，deployOnStartup为true时，Tomcat在启动时检查Web应用，且检测到的所有Web应用视作新应用；autoDeploy为true时，Tomcat在运行时定期检查新的Web应用或Web应用的更新。Host元素的appBase和xmlBase设置了检查Web应用更新的目录。appBase属性指定Web应用所在的目录，默认值是webapps，xmlBase属性指定Web应用的XML配置文件所在的目录，默认值为conf/<engine_name>/<host_name>

如何修改tomcat的端口号

进入Tomcat的安装目录，在conf目录下找到sever.xml进行修改

 

tomcat配置虚拟主机

修改server.xml在里面添加一个host标签

 

tomcat启动和关闭

启动要设置环境变量JAVA_HOME,如果没有配置启动会报错

 

在window中

点击startup.bat进行启动（如果启动失败命令窗口会一闪而过）

命令行找到目录运行startup.bat（如果失败会输出原因）

关闭shutdown.bat

在linux中

运行startup.sh

关闭shutdown.sh

 

 

（eclipse不需要配置JAVA_HOME,当安装 jdk/jre 时会自动复制java.exe 到 C:\Windows\System32。eclipse.exe 使用这个java.exe 运行。）

 

查看tomcat是否运行

window中：

 

方法一：

netstat -ano|findstr 8080

TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       118880

TCP    [::]:8080              [::]:0                 LISTENING       118880

netstat命令的功能是显示网络连接、路由表和网络接口信息

结果分别代表协议，内部地址，外部地址，状态，进程id

方法二：

jsp -l或jps -v

jsp -l会打印进程号+主类完全名/jar名

118880 org.apache.catalina.startup.Bootstrap

jps -v 会打印进程号+主类名/jar名 +虚拟机启动参数

118880 Bootstrap -Djdk.tls.ephemeralDHKeySize=2048

 

杀掉tomcat进程

taskkill /f /pid 118880

 

 

linux查看：

ps -ef |grep tomcat

杀掉：

kill -9 118880

tomcat启动过程

1）初始化守护进程，其实就是初始化类加载器

2）加载相关配置文件，初始化几个主要的顶层接口实例，简单了说，就是服务器初始化。

  • 启动那些有生命周期的顶层实例，监听用户请求，简单了说，就是启动服务器。

 

 

tomcat7:

tomcat启动时我们调用startup.bat或者startup.sh来进行启动，他们会最终执行catalina.bat/sh 脚本文件,而catalina脚本执行会调用tomcat源码中的Bootstrap类的main方法（tomcat还支持debug模式等方式启动都是catalina脚本调用main方法只是传入的参数不一样，停用tomcat也是不过传的参数是stop）

main方法会分别执行Bootstrap类中的init()、load()、start()；（init方法中通过反射创建了Catalina实例，load方法和start方法都是调用的Catalina的load方法和start方法）

  • init方法：主要设置了一下环境变量和创建类加载器对象
  • load方法：主要创建一些目录，根据xml的配置实例化组件（实例化Server、Service、Connector、Engine、Host等组件），并初始化部分组件（Server,Service,Engine、Connector等）
  • start方法：依次启动Server,service,Engine,Executor,Connector组件（就是调用他们的start方法）webapp的部署会在Engine组件启动过程中进行（Engine组件会启动其下的子容器，Context组件会通过 xml 或者 扫描 class 字节码读取 servlet3.0 的注解配置，从而加载 webapp 定义的 Listener、Servlet、Filter 等 servlet 组件，但是并不会立即实例化对象。全部加载完毕之后，依次对 Listener、Filter、Servlet 进行实例化、并且调用其初始化方法（servlet如果没有配置load-on-startup或为负数这里不进行实例化和初始化，将在获取到请求的时候进行））（Engine组件启动过程中会创建CatalinaBackgroundProcessor守护线程，Connector组件启动过程了创建和启动了http和ajp对应的4个守护线程），

 

<Host name="localhost"  appBase="webapps" unpackWARs="true" autoDeploy="true">

所以会加载webapps下载的war包或者文件夹

 

tomcat启动过程中创建了main用户线程和监控http请求的守护线程

启动过程中创建的守护线程：

CatalinaBackgroundProcessor：热部署相关的线程

http-bio-8080-Acceptor-0 ：Acceptor线程用于监听8080端口的客户端连接

http-bio-8080-AsyncTimeout：AsyncTimeout线程检测超时的请求，并将该请求再转发到工作线程池

ajp-bio-8080-Acceptor-0

ajp-bio-8080-AsyncTimeout

 

tomcat在请求过来时初始化工作线程池

 

tomcat的关闭：

一般来说关闭 Tomcat 通过执行 shutdown.bat/sh 脚本，最终会执行Bootstrap类的 main 方法，并传入入参"stop",main线程会向localhost:8005发起一个 Socket 连接，并写入SHUTDOWN字符串。这样将会关闭 Tomcat 中的main线程，之后守护线程关闭，服务器就关闭完了

 

tomcat用户管理

tomcat可以配置用户名，密码，角色来进行登陆管理tomcat，一个用户可以配置多个角色

在conf文件夹下的tomcat-users.xml中配置，配置完要重启（默认没有设置用户，所以需要添加用户才能够管理）

<role rolename="admin-gui"/>

<role rolename="manager-gui"/>

<user username="admin" password="admin" roles="manager-gui,admin-gui"/>

配置完重启tomcat就可以登录

 

角色有：

admin-gui?— 可访问 "host管理" 页面，但"APP管理" 和 "服务器状态" 页面无查看权限

manager-gui?— 无 "host管理" 页面访问权限，有"APP管理" 和 "服务器状态" 页面查看权限

manager-status?— 只有"服务器状态" 页面查看权限

manager-script?— 有脚本方式管理接口访问权限和"服务器状态" 页面查看权限

manager-jmx?— JMX 代理接口访问权限和"服务器状态" 页面查看权限

admin-script?— 只有host-manager脚本方式管理接口访问权限

 

 

Tomcat的优化经验

Tomcat内存优化：有富余物理内存的情况，加大tomcat使用的jvm的内存；（bin目录下Windows系统catalina.bat,Unix系统catalina.sh中JAVA_OPTS中设置）

Tomcat并发优化：调整连接线程数（在Tomcat配置文件server.xml中配置）

 

查看tomcat内存情况

可以登录tomcat的管理页面查看服务器状态来查看，

Free memory:当前可用的内存；

Total memory:当前已经分配的JVM内存；

Max memory:当前允许分配的最大JVM内存

 

也可以使用监控工具进行查看 jstat，jmap,jvisualvm等

 

 

修改tomcat的jvm内存

默认设置：

Tomcat默认初始堆内存是物理内存的1/64，默认最大堆内存是物理内存的1/4，默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。

 

建议设置：

建议初始内存和最大内存均设为物理内存的一半，不可超过物理内存。

 

 

Windows系统catalina.bat,Unix系统 TOMCAT_HOME/bin/catalina.sh

在“echo "Using CATALINA_BASE:   $CATALINA_BASE"”上面加入以下行：

 

JAVA_OPTS="-server -XX:PermSize=512M -XX:MaxPermSize=1024m"

重启tomcat

 

-server：一定要作为第一个参数，在多个CPU时性能佳

-Xms：java Heap初始大小。 默认是物理内存的1/64。初始总堆内存，一般将它设置的和最大堆内存一样大，这样就不需要根据当前堆使用情况而调整堆的大小了

-Xmx：java heap最大值。建议均设为物理内存的一半。不可超过物理内存。

-XX:PermSize：设定内存的永久保存区初始大小。持久带堆的初始大小，缺省值为64M。

-XX:MaxPermSize：设定内存的永久保存区最大大小。持久带堆的最大大小，缺省值为64M。

-Xmn：young generation(年轻代)的heap大小。一般设置为Xmx的3、4分之一，sun官方推荐为整个堆的3/8，

 

堆内存的组成 总堆内存 = 年轻带堆内存 + 年老带堆内存 + 持久带堆内存

一般MaxPermSize和MinPermSize也设置一样大，这样可以减轻伸缩堆大小带来的压力。

 

tomcat常见的线程

tomcat中有的线程使用了线程池，有的没有使用线程池

 

Main线程：主线程，负责启动tomcat（tomcat项目中的BootStarp类的main方法，main线程是一个用户线程，关闭tomcat会关闭main线程，）

Work线程：HTTP请求的处理线程，名称是http-[IpAddr]-[Port]-[Number]，如http-0.0.0.0-8080-1

Acceptor线程：获得HTTP请求socket。并从工作线程池中获得一个线程，将socket分配给一个工作线程。名称http-[IPAddr]-[Port]-Acceptor-[Number]，如http-0.0.0.0-8080-Acceptor-1

catalina-exec线程：功能和Work线程类似。如果为Connector配置了Executor，则会使用该线程处理http请求。所属线程池:StandardThreadExecutor，该线程池类通过代理设计模式对Java Concurrent包中的线程池ThreadPoolExecutor进行简单的封装。在tomcat的Server.xml文件中配置Executor，默认前缀为catalina-exec-

TP-Monitor线程：监控ThreadPool线程池的空闲线程，回收比最大空闲线程数多出的空闲线程

 

main线程说明

main线程

 

Tomcat并发优化

tomcat并发量与其配置息息相关，一般的机器几百的并发量足矣，如果设置太高可能引发各种问题，内存、网络等问题也能在高并发下暴露出来

maxThreads最大线程数代表的是tomcat支持的最大并发量,Tomcat7和8默认是200

 

tomcat连接数线程池设置

在tomcat配置文件server.xml中的配置中，和连接数相关的参数有：

tomcat7以上

acceptCount、maxConnections、maxThreads

acceptCount（连接队列的长度）

当连接队列中连接的个数达到acceptCount时，队列满，进来的请求一律被拒绝(connection refused)。默认值是100。它里面的连接是还未被处理的连接

 

连接与请求的关系：连接是TCP层面的（传输层），对应socket；请求是HTTP层面的（应用层），必须依赖于TCP的连接实现；一个TCP连接中可能传输多个HTTP请求。

 

maxConnections（最大连接数）

Tomcat处理的最大连接数。表示最多可以有多少个socket连接到tomcat上，它代表的是正在被tomcat处理的连接，当Tomcat接收的连接数达到maxConnections时，Acceptor线程不会读取accept队列中的连接；这时accept队列中的连接会一直阻塞着，直到Tomcat接收的连接数小于maxConnections。如果设置为-1，则连接数不受限制。

默认值与连接器使用的协议有关：NIO的默认值是10000，APR/native的默认值是8192，而BIO的默认值为maxThreads（如果配置了Executor，则默认值是Executor的maxThreads）。

配置说明：使用BIO，那么值应该与maxThreads一致；如果是NIO，值应该远大于maxThreads

 

maxThreads（最大并发线程数量）

请求处理线程的最大数量。默认值是200（Tomcat7和8都是的）。如果该Connector绑定了Executor，这个值会被忽略，因为该Connector将使用绑定的Executor，而不是内置的线程池来执行任务。

maxConnections的设置与Tomcat的运行模式有关。如果tomcat使用的是BIO，那么maxConnections的值应该与maxThreads一致；如果tomcat使用的是NIO，那么类似于Tomcat的默认值，maxConnections值应该远大于maxThreads。

 

 

web server允许的最大连接数还受制于操作系统的内核参数设置，通常Windows每个进程中的线程数不允许超过2000，Linux是每个进程中的线程数不允许超过1000。

 

总结：

要调整Tomcat的默认最大连接数，可以增加acceptCount、maxThreads这两个属性的值，并且使acceptCount大于等于maxThreads：

流程：

客户端请求过来，经过tcp三次握手建立连接，连接放入到accept队列，工作线程从队列中获取连接并处理，当工作线程获取的连接数达到maxConnections，accept队列中的连接处在无法被处理阻塞的状态（如果acceptCount未满还可以往里面放连接）

所以tomcat可以接收的最大连接数为acceptCount+maxConnections

 

最大线程数和qps

最大线程数是可以同时工作的最大线程

qps是单位时间内的访问量

如果要计算tomcat支持的最大qps

qps=最大线程数*（单位时间一个线程处理的访问量）

 

 

Tomcat垃圾回收

 

垃圾回收(gc)机制非常重要，有时系统会因为内存没有及时回收导致内存溢出，或是内存饱和出现无法响应用户请求的情况，这就要要求我们对空闲内存进行清理，以确保系统正常运行，tomcat GC的最佳配置是确保系统正常运行的关键。

 

Window在bin下的catalina.bat,linux在catalina.sh文件中echo Using CATALINA_BASE:   "%CATALINA_BASE%"的前一行加入如下代码。

set JAVA_OPTS=%JAVA_OPTS%

-server -Xms8192m -Xmx8192m -Xmn1890m -verbose:gc

-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=5 -XX:+ExplicitGCInvokesConcurrent -XX:GCTimeRatio=19 -XX:CMSInitiatingOccupancyFraction=70 -XX:CMSFullGCsBeforeCompaction=0 -Xnoclassgc -XX:SoftRefLRUPolicyMSPerMB=0

 

 *要把以上代码写在一行才能生效。*

 

tomcat接收请求的方式

 

BIO:由于每个请求都要创建一个线程来处理，线程开销较大，不能处理高并发的场景，在三种模式中性能也最低

nio:是一个基于缓冲区、并能提供非阻塞I/O操作的Java API，它拥有比传统I/O操作(bio)更好的并发运行性能。

Apr是在Tomcat上运行高并发应用的首选模式，但是需要安装apr、apr-utils、tomcat-native等包。从操作系统级别解决异步IO问题，大幅度的提高服务器的处理和响应性能.

(Apache Portable Runtime/Apache可移植运行库)

 

tomcat启动日志中可以看到：

信息: Starting ProtocolHandler ["http-bio-8080"] 

说明就是用的bio

bootstrap和tomcat

tomcat启动会调用的org.apache.catalina.startup.Bootstrap类中的main方法进行启动，所以Bootstrap类是tomcat启动的入口类，所以我们查看tomcat的进程的时候看到的是Bootstrap

Catalina类负责启动、停止应用服务器

bootstrap负责创建Catalina实例，根据执行参数调用Catalina相关方法完成针对应用服务器的操作（启动、停止）。

tomcat的session有效期

在conf/web.xml中定义了session的有效期默认是30分钟，设置为0，-1 表示 永不超时

 

项目中可以在web.xml中，设置

<session-config>
        <session-timeout>30</session-timeout>
    </session-config>

项目中的优先级高于tomcat的设置

HTTP 是一个无状态的协议, 这意味着每次发起的HTTP请求, 都是一个全新的请求，而 Session 的出现就是为了解决这个问题, 将 Client 端的每次请求都关联起来, 要实现 Session 机制通常通过 Cookie，URI 附加参数等传递请求信息，session来存储客户端在同一个会话期间的一些数据（比如用户登陆信息）；

 

session底层的数据结构是ConcurrentHashMap

weblogic

WebLogic更加强大，适用于大型项目，适用于个性化电子商务应用系统

WebLogic应该是J2EE Container(Web Container + EJB Container + XXX规范)！

Tomcat只能算Web Container 不支持EJB

Tomcat开源免费。

WebLogic不开源不免费。

posted @ 2023-02-02 10:11  星光闪闪  阅读(178)  评论(0)    收藏  举报