weixin_42073629的博客

对于生产环境有了一定规模的tomcat集群业务来说,要实现session会话共享,比较稳妥的方式就是使用数据库持久化session.为什么要持久化session（共享session）呢？因为在客户端每个用户的Session对象存在Servlet容器中，如果Tomcat服务器重启或者宕机的话，那么该session就会丢失，而客户端的操作会由于session丢失而造成数据丢失；如果当前用户访问量巨大，每个用户的Session里存放大量数据的话，那么就很占用服务器大量的内存，进而致使服务器性能受到影响。数据库持久

对于web应用集群的技术实现而言，最大的难点就是：如何能在集群中的多个节点之间保持数据的一致性，会话（Session）信息是这些数据中最重要的一块。要实现这一点， 大体上有两种方式： 一种是把所有Session数据放到一台服务器上或者数据库中，集群中的所有节点通过访问这台Session服务器来获取数据； 另一种就是在集群中的所有节点间进行Session数据的同步拷贝，任何一个节点均保存了所有的Session数据。 在集群系统下实现session统一的有如下几种方案： 1) 请求精确定位：session s

一般来说,在多个tomcat集群业务中,session会话共享是必须的需求,不然前端nginx转发过来的请求不知道之前请求在哪台tomcat节点上，从而就找不到session以至于最终导致请求失败。要实现tomcat session共享有多种方案,今天介绍下使用tomcat自带的cluster方式，在多个tomcat节点间自动实时复制session信息，配置起来很简单。tomcat自带的这种session共享方案,对于规模较小的tomcat集群来说够用了，但这个方案的效率比较低，在大并发下表现并不好。所以大

这次主要解析采用apr方式处理请求.apr用C实现，通过JNI调用,主要提升对静态资源（如HTML、图片、CSS、JS等）的访问性能.在tomcat下配置apr步骤: 1.下载本地库tcnative-1.dll,放在%jdk%\bin目录下(见附件). 2.在server.xml里配置listener,这个配置server.xml默认是有的 Xml代码 <Listener className="org.apache.catalina.core.AprLifecycleListen...

这次主要解析采用IO方式处理请求.在Server.xml的配置如下: Xml代码 <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /> 在tomcat启动的时候,会调用Connector类的Start()方法,根据以上配置,Connector的start()方法里会调用Http11Protocol类.

Connector类的相关配置在Tomcat的安装目录conf下的Server.xml文件里,我这次主要解析采用NIO方式处理请求的情况.在Server.xml的配置如下: Xml代码 <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443" /> .

一. tomcat的容器组件 1.Engine,实现类StandardEngine 2.Host,实现类StandardHost 3.Context,实现类StandardContext 4.Wrapper,实现类StandardWrapper 容器类之间的关系如下: 容器的初始化顺序: 二. tomcat的连接器组件 tomcat服务器在启动后,可以对外提供多个服务(默认只提供一个服务,见S...

Tomcat 的 Connector 有三种运行模式 bio、nio、apr ，先了解一下这三种的区别。 bio(blocking I/O)，顾名思义即阻塞式 I/O 操作，表示 Tomcat 使用的是传统的 Java I/O 操作(即java.io包及其子包)。Tomcat 在默认情况下，就是以 bio 模式运行的。一般而言 bio 模式是三种运行模式中性能最低的一种。 nio(new I/O)，是 Java SE 1.4 及后续版本提供的一种新的 I/O 操作方式(即java.nio包及其子包)。J

如上一篇文章所见 Standard MBean 在 Tomcat 源码中的例子并不多，在 jconsole 中所看到的大量 MBean（如 Catalina 下的 Connector、Engine、Server、Service 等），实际上是动态 MBean（Dynamic MBean）。本文主要讲述 Tomcat 7 中如何通过动态 MBean 的方式构造 MBean 的。 接触过动态 MBean 的朋友一定知道，它的实例肯定要实现一个接口，即javax.management.DynamicMBean。

做过 Java 平台下的应用服务器监控的对 JMX 应该不会陌生，简单说 JMX 就是提供了一个标准的管理方案的框架。这里所说的管理的含义包括监控平台运行状况、应用级别配置资源、收集应用统计数据、调试、监视服务器性能，JMX 允许你将所有的资源（硬件和软件）打包成 java 对象，然后将他们暴露在分布式环境中，并且 JMX 提供了一个机制，可以很简单的将既存的管理协议，如 SNMP ，映射到 JMX 自己的管理结构中。 本文重点不是介绍 JMX ，而是分析 Tomcat 7 中是如何用 JMX 来提供管理

在一般的 web 应用开发里通常会使用开发工具（如 Eclipse、IntelJ ）集成 tomcat ，这样可以将 web 工程项目直接发布到 tomcat 中，然后一键启动。经常遇到的一种情况是直接修改一个类的源文件，此时开发工具会直接将编译后的 class 文件发布到 tomcat 的 web 工程里，但如果 tomcat 没有配置应用的自动加载功能的话，当前 JVM 中运行的 class 还是源文件修改之前编译好的 class 文件。可以重启 tomcat 来加载新的 class 文件，但这样做需要

分析到了org.apache.catalina.deploy.WebXml类的 configureContext 方法，可以看到在这个方法中通过各种 setXXX、addXXX 方法的调用，使得每个应用中的 web.xml 文件的解析后将应用内部的表示 Servlet、Listener、Filter 的配置信息与表示一个 web 应用的 Context 对象关联起来。 这里列出 configureContext 方法中与 Servlet、Listener、Filter 的配置信息设置相关的调用代码：

讲了org.apache.catalina.startup.HostConfig的 lifecycleEvent 方法中所做的事情。最后看到在 Tomcat 启动时或启动后（后台线程定时扫描）会调用 HostConfig 类的 deployApps 方法： 可以看到这里部署应用有三种方式：XML 文件描述符、WAR 包、文件目录。三种方式部署的总体流程很相似，都是一个 web 应用分配一个线程来处理，这里统一放到与 Host 内部的线程池对象中（ startStopExecutor ），所以有时会看到

为什么关心 Tomcat 中一个 web 应用的加载过程？在前面的文章中看过多次 Tomcat 的组件结构图，这里再贴出来回顾一下： 之前的 Tomcat 7 启动分析 系列文章中看到 Tomcat 启动的时候将会解析 server.xml，根据里面所配置的各个节点信息逐一初始化和启动相应组件（即分别调用它们的 init 和 start 方法），但浏览一下 Tomcat 7 源码中的 server.xml 的内容，里面对应上图中的已经默认配置的各级组件包括 Server、Service、Engin

通过这一系列的前三部分看到了一次客户端连接在 Tomcat 内部被转换成了请求对象（org.apache.catalina.connector.Request类的实例），并在该请求对象内部将与本次请求相关的 Host、Context、Wrapper 对象的引用。本文主要分析该请求对象在容器内部流转的经过。 再来看一下 Tomcat 7 内部的组件结构图： 其实这张图已经给出了答案，在 Connector 接收到一次连接并转化成请求（ Request ）后，会将请求传递到 Engine 的管道（ Pi

上文分析到了org.apache.coyote.http11.AbstractHttp11Processor类 process 方法，以解析请求头的 getInputBuffer().parseRequestLine 方法调用为例，看到如何从 Socket 的 IO 流中取出字节流数据，根据 Http 协议将字节流组装到 Tomcat 内部的org.apache.coyote.Request对象的相关属性中。 接下来将会解释构造好的 Tomcat 的内部请求对象从 Connector 到 Engine 到

先抛开之前所看到的 Tomcat 源码不谈，Tomcat 作为一个用 Java 实现的 Web 服务器，如果让你来实现，那么从何入手？ 这里首先需要厘清的是 Web 服务器的概念，谷歌了一下，发现这条解释还算靠谱点，【在网络环境下可以向发出请求的浏览器提供文档的程序】。重点有两条：1.网络环境下，2.能够给出响应。用 Java 写过网络通信程序的都知道，这里必然会用到 Socket 编程。我们自己要实现的服务器程序作为 Socket 编程里的服务端，浏览器作为 Socket 编程里的客户端。 要理解 T

在默认的配置下Tomcat启动好之后会看到后台上总共有6个线程在运行。其中1个用户线程，剩下5个为守护线程（如下图所示）。 如果你对用户线程、守护线程等概念不熟悉，请参看前一篇文章—— Tomcat 7 服务器关闭原理 。 这里重点关注以 http-bio-8080 开头的两个守护线程（即 http-bio-8080-Acceptor-0 和 http-bio-8080-AsyncTimeout ），因为这是我们在 Tomcat 的默认配置下发布 web 应用时实际处理请求的线程。先看下这两个线程

在默认的配置下启动完之后会看到后台实际上总共有 6 个线程在运行。即 1 个用户线程，剩下 5 个为守护线程(下图中的 Daemon Thread )。 如果对什么叫守护线程的概念比较陌生，这里再重复一下： 所谓守护线程，是指在程序运行的时候在后台提供一种通用服务的线程，比如垃圾回收线程。这种线程并不属于程序中不可或缺的部分，当所有的非守护线程结束时，程序也就终止了，同时会杀死进程中的所有守护线程。反过来说，只要任何非守护线程还在运行，程序就不会终止。 用户线程和守护线程两者几乎没有区别，唯一的不

看到有一个 setStateInternal 方法的调用，在查看 LifecycleBase 类及其它各组件的源码时会在多处看到这个方法的调用，这篇文章就来说说这方法，以及与这个方法相关的 Tomcat 的 Lifecycle 机制和实现原理。 接上文里谈到了 Tomcat 7 的各组件的父类 LifecycleBase 类，该类实现了接口 org.apache.catalina.Lifecycle，下面是这个接口里定义的常量和方法： 细心的读者会发现，上篇文章里提到的 init 和 start 方

在正常启动 Tomcat 7 的情况下，上篇文章分析到了执行 org.apache.catalina.core.StandardServer 的 init 和 start 方法这儿，那么就来看看这两个方法里面到底干了些什么。 但是在 StandardServer 类里面并没有发现这两个方法： 由此推知这两方法必定是在该类的父类中已实现了，在 StandardServer 类的父类 LifecycleMBeanBase 类的父类 LifecycleBase 类里面终于找到了这两个方法的实现，下面先来看

前一篇文章里最后看到 Bootstrap 的 main 方法最后会调用 org.apache.catalina.startup.Catalina 对象的 load 和 start 两个方法，那么就来看看这两个方法里面到底做了些什么。 load 方法： 1 /** 2 * Start a new server instance. 3 */ 4 public void load() { 5 6 long t1 = System.n

之前分析了 Tomcat 的启动脚本，如果从 startup.bat 开始启动 Tomcat 的话会发现最后会调用 org.apache.catalina.startup.Bootstrap 里的 main 方法，并且传过来的最后一个命令行参数是 start，接下来的启动代码分析就从这里开始。 先看下这个 main 方法的代码： 1 /** 2 * Main method and entry point when starting Tomcat via the provided 3

前面通过直接运行 BootStarp 的 main 函数来启动的，只是加了一个 catalina.home 的系统属性。而正常情况下启动 Tomcat 是通过运行脚本的方式，这个就涉及到建立工程时拷贝过来的 script 目录下的一堆脚本文件了。 以我的 windows 系统举例，实际上最终是执行 startup.bat 这个批处理文件来启动 tomcat 的。 那么启动分析就冲这个文件开始吧： 一、分析 startup.bat 文件 startup.bat : 1 @echo off 2

源码分析的环境搭建吧，用的是 eclipse Juno Service Release 1，然后在 tomcat官网下了tomcat7.0.42的源码，这两样准备好之后便是搭建能够运行源码的调试环境了。 在 eclipse 中新建一个 java 项目，项目取名 tc7.0.42 JRE 选择 1.6 的 其他设置默认 \2. 将下载的 tomcat 源码包解压开，并拷贝到 Eclipse 里新建的项目根目录下 注意，我这里将源码解压开后的 bin 目录重命名成 script 之后才拷贝的，因为新..

一、概述 作为一个成熟的中间件产品，tomcat有很多值得我们学习的地方。下面我将从tomcat的运行脚本catalina.sh入手，分析tomcat的启动过程，以及tomcat脚本是如何实现停止tomcat服务的。 注意：此处分析的是linux环境下的脚本文件 二、tomcat目录结构 tomcat目录结构如下： bin目录的内容如下： 可执行文件，包括startup.sh、shutdown.sh、catalina.sh tomcat启动所依赖的jar包，包括 bootstrap.jar

本文档是身边一些朋友、技术大佬之前分享的一些笔记，记录了 Tomcat 优化方法，笔记较多而且比较杂乱，经过整理、分类我个人觉得大致可以从以下几个方面优化 Tomcat： Tomcat 运行模式 Tomcat 配置优化 JVM 优化 内核参数优化 一、修改 Tomcat 运行模式 Tomcat Connector有三种运行模式： bio：阻塞 IO bio 是三种运行模式中性能最低...

面试时问到Tomcat相关问题的几率并不高，正式因为如此，很多人忽略了对Tomcat相关技能的掌握，下面这一篇文章整理了Tomcat相关的系统架构，介绍了Server、Service、Connector、Container之间的关系，各个模块的功能，可以说把这几个掌握住了，Tomcat相关的面试题你就不会有任何问题了！另外，在面试的时候你还要有意识无意识的往Tomcat这个地方引，就比如说常见的Spring MVC的执行流程，一个URL的完整调用链路，这些相关的题目你是可以往Tomcat处理请求的这个过程去