获取 Tomcat 7.0 的最简单方法：快速且简单的下载步骤 (获取tomcat线程池对象)

其实，大部分 Java 开发同学知道这两种线程池的特性，只是抱有侥幸心理，觉得只是使用线程池做一些轻量级的任务，不可能造成队列积压或开启大量线程。

但，现实往往是残酷的。 我之前就遇到过这么一个事故：用户注册后，我们调用一个外部服务去发送短信，发送短信接口正常时可以在 100 毫秒内响应，TPS 100 的注册量，CachedThreadPool 能稳定在占用 10 个左右线程的情况下满足需求。 在某个时间点，外部短信服务不可用了，我们调用这个服务的超时又特别长，比如 1 分钟，1 分钟可能就进来了 6000 用户，产生 6000 个发送短信的任务，需要 6000 个线程，没多久就因为无法创建线程导致了 OOM，整个应用程序崩溃。

因此，我同样不建议使用 Executors 提供的两种快捷的线程池，原因如下：

我们需要根据自己的场景、并发情况来评估线程池的几个核心参数，包括核心线程数、最大线程数、线程回收策略、工作队列的类型，以及拒绝策略，确保线程池的工作行为符合需求，一般都需要设置有界的工作队列和可控的线程数。

任何时候，都应该为自定义线程池指定有意义的名称，以方便排查问题。 当出现线程数量暴增、线程死锁、线程占用大量 CPU、线程执行出现异常等问题时，我们往往会抓取线程栈。 此时，有意义的线程名称，就可以方便我们定位问题。

除了建议手动声明线程池以外，我还建议用一些监控手段来观察线程池的状态。 线程池这个组件往往会表现得任劳任怨、默默无闻，除非是出现了拒绝策略，否则压力再大都不会抛出一个异常。 如果我们能提前观察到线程池队列的积压，或者线程数量的快速膨胀，往往可以提早发现并解决问题。

在之前的 Demo 中，我们用一个 printStats 方法实现了最简陋的监控，每秒输出一次线程池的基本内部信息，包括线程数、活跃线程数、完成了多少任务，以及队列中还有多少积压任务等信息：

接下来，我们就利用这个方法来观察一下线程池的基本特性吧。

首先，自定义一个线程池。 这个线程池具有 2 个核心线程、5 个最大线程、使用容量为 10 的 ArrayBlockingQueue 阻塞队列作为工作队列，使用默认的 AbortPolicy 拒绝策略，也就是任务添加到线程池失败会抛出 RejectedExecutionException。 此外，我们借助了 Jodd 类库的 ThreadFactoryBuilder 方法来构造一个线程工厂，实现线程池线程的自定义命名。

60 秒后页面输出了 17，有 3 次提交失败了

并且日志中也出现了 3 次类似的错误信息：

我们把 printStats 方法打印出的日志绘制成图表，得出如下曲线：

至此，我们可以总结出线程池默认的工作行为：

不会初始化 corePoolSize 个线程，有任务来了才创建工作线程；

当核心线程满了之后不会立即扩容线程池，而是把任务堆积到工作队列中；

当工作队列满了后扩容线程池，一直到线程个数达到 maximumPoolSize 为止；

如果队列已满且达到了最大线程后还有任务进来，按照拒绝策略处理；

当线程数大于核心线程数时，线程等待 keepAliveTime 后还是没有任务需要处理的话，收缩线程到核心线程数。

了解这个策略，有助于我们根据实际的容量规划需求，为线程池设置合适的初始化参数。当然，我们也可以通过一些手段来改变这些默认工作行为，比如：

声明线程池后立即调用 prestartAllCoreThreads 方法，来启动所有核心线程；

传入 true 给 allowCoreThreadTimeOut 方法，来让线程池在空闲的时候同样回收核心线程。

不知道你有没有想过：Java 线程池是先用工作队列来存放来不及处理的任务，满了之后再扩容线程池。 当我们的工作队列设置得很大时，最大线程数这个参数显得没有意义，因为队列很难满，或者到满的时候再去扩容线程池已经于事无那么，我们有没有办法让线程池更激进一点，优先开启更多的线程，而把队列当成一个后备方案呢？比如我们这个例子，任务执行得很慢，需要 10 秒，如果线程池可以优先扩容到 5 个最大线程，那么这些任务最终都可以完成，而不会因为线程池扩容过晚导致慢任务来不及处理。

这里我只给你一个大致思路：

由于线程池在工作队列满了无法入队的情况下会扩容线程池，那么我们是否可以重写队列的 offer 方法，造成这个队列已满的假象呢？

由于我们 Hack 了队列，在达到了最大线程后势必会触发拒绝策略，那么能否实现一个自定义的拒绝策略处理程序，这个时候再把任务真正插入队列呢？

接下来，就请你动手试试看如何实现这样一个“弹性”线程池吧。 Tomcat 线程池也实现了类似的效果，可供你借鉴。

不久之前我遇到了这样一个事故：某项目生产环境时不时有报警提示线程数过多，超过 2000 个，收到报警后查看监控发现，瞬时线程数比较多但过一会儿又会降下来，线程数抖动很厉害，而应用的访问量变化不大。

为了定位问题，我们在线程数比较高的时候进行线程栈抓取，抓取后发现内存中有 1000 多个自定义线程池。 一般而言，线程池肯定是复用的，有 5 个以内的线程池都可以认为正常，而 1000 多个线程池肯定不正常。

在项目代码里，我们没有搜到声明线程池的地方，搜索 execute 关键字后定位到，原来是业务代码调用了一个类库来获得线程池，类似如下的业务代码：调用 ThreadPoolHelper 的 getThreadPool 方法来获得线程池，然后提交数个任务到线程池处理，看不出什么异常。

但是，来到 ThreadPoolHelper 的实现让人大跌眼镜，getThreadPool 方法居然是每次都使用 来创建一个线程池。

我们可以想到 newCachedThreadPool 会在需要时创建必要多的线程，业务代码的一次业务操作会向线程池提交多个慢任务，这样执行一次业务操作就会开启多个线程。 如果业务操作并发量较大的话，的确有可能一下子开启几千个线程。

那，为什么我们能在监控中看到线程数量会下降，而不会撑爆内存呢？

回到 newCachedThreadPool 的定义就会发现，它的核心线程数是 0，而 keepAliveTime 是 60 秒，也就是在 60 秒之后所有的线程都是可以回收的。 好吧，就因为这个特性，我们的业务程序死得没太难看。

要修复这个 Bug 也很简单，使用一个静态字段来存放线程池的引用，返回线程池的代码直接返回这个静态字段即可。 这里一定要记得我们的最佳实践，手动创建线程池。 修复后的 ThreadPoolHelper 类如下：

线程池的意义在于复用，那这是不是意味着程序应该始终使用一个线程池呢？要根据任务的“轻重缓急”来指定线程池的核心参数，包括线程数、回收策略和任务队列：对于执行比较慢、数量不大的 IO 任务，或许要考虑更多的线程数，而不需要太大的队列。 而对于吞吐量较大的计算型任务，线程数量不宜过多，可以是 CPU 核数或核数2倍（理由是，线程一定调度到某个 CPU 进行执行，如果任务本身是 CPU 绑定的任务，那么过多的线程只会增加线程切换的开销，并不能提升吞吐量），但可能需要较长的队列来做缓冲。

业务代码使用了线程池异步处理一些内存中的数据，但通过监控发现处理得非常慢，整个处理过程都是内存中的计算不涉及 IO 操作，也需要数秒的处理时间，应用程序 CPU 占用也不是特别高，有点不可思议。

经排查发现，业务代码使用的线程池，还被一个后台的文件批处理任务用到了。或许是够用就好的原则，这个线程池只有 2 个核心线程，最大线程也是 2，使用了容量为 100 的 ArrayBlockingQueue 作为工作队列，使用了 CallerRunsPolicy 拒绝策略：

这里模拟一下文件批处理的代码，在程序启动后通过一个线程开启死循环逻辑，不断向线程池提交任务，任务的逻辑是向一个文件中写入大量的数据：

可以想象到，这个线程池中的 2 个线程任务是相当重的。通过 printStats 方法打印出的日志，我们观察下线程池的负担：

可以看到，线程池的 2 个线程始终处于活跃状态，队列也基本处于打满状态。 因为开启了 CallerRunsPolicy 拒绝处理策略，所以当线程满载队列也满的情况下，任务会在提交任务的线程，或者说调用 execute 方法的线程执行，也就是说不能认为提交到线程池的任务就一定是异步处理的。 如果使用了 CallerRunsPolicy 策略，那么有可能异步任务变为同步执行。 从日志的第四行也可以看到这点。 这也是这个拒绝策略比较特别的原因。

不知道写代码的同学为什么设置这个策略，或许是测试时发现线程池因为任务处理不过来出现了异常，而又不希望线程池丢弃任务，所以最终选择了这样的拒绝策略。 不管怎样，这些日志足以说明线程池是饱和状态。

可以想象到，业务代码复用这样的线程池来做内存计算，命运一定是悲惨的。我们写一段代码测试下，向线程池提交一个简单的任务，这个任务只是休眠 10 毫秒没有其他逻辑：

我们使用 wrk 工具对这个接口进行一个简单的压测，可以看到 TPS 为 75，性能的确非常差。

细想一下，问题其实没有这么简单。 因为原来执行 IO 任务的线程池使用的是 CallerRunsPolicy 策略，所以直接使用这个线程池进行异步计算的话，当线程池饱和的时候，计算任务会在执行 Web 请求的 Tomcat 线程执行，这时就会进一步影响到其他同步处理的线程，甚至造成整个应用程序崩溃。

解决方案很简单，使用独立的线程池来做这样的“计算任务”即可。计算任务打

Netty网络编程框架的核心概念以及入门案例

本文详细介绍了Netty网络编程框架的核心概念以及入门案例。

基于事件驱动的JavaNIO网络通信框架，可以快速简单地开发网络应用程序。

极大地简化并优化了TCP和UDP套接字服务器等网络编程，并且性能以及安全性等很多方面甚至都要更好。

支持多种通信协议如FTP，SMTP，HTTP以及各种二进制和基于文本的传统协议，同样支持自定义协议。

简单的说，Netty有三个优点：

高并发：基于NIO开发（Reactor模型），并发性能相比BIO得到了很大提高。

传输快：传输依赖于零拷贝特性，尽量减少不必要的内存拷贝，使用高性能序列化协议protobuf，实现了高效传输。

封装好：封装了原始NIO编程的很多细节，提供了易于使用调用接口，使用更简单。

借用官方的描述：Netty成功地找到了一种在不妥协可维护性和性能的情况下实现易于开发，性能，稳定性和灵活性的方法。

Netty的社区目前非常活跃。 很多涉及到网络调用的开源项目和框架底层都用到了Netty，比如我们常用的Dubbo、RocketMQ、Elasticsearch、gRPC、Spark、GateWay等等。

总之，涉及到网络编程开发时，比如即时通讯系统、自定义RPC框架、自定义HTTP服务器、实时消息推送系统等场景下，用Netty，准没错。

通道，Netty网络操作抽象类，包括基本的I/O操作，如bind、connect、read、write等，Netty的Channel接口所提供的API，大大地降低了直接使用Socket类的复杂性。

不同协议、不同的阻塞类型的连接都有不同的Channel类型与之对应，下面是一些常用的Channel类型：

NioSocketChannel，异步的客户端TCPSocket连接。

NioServerSocketChannel，异步的服务器端TCPSocket连接。

NioDatagramChannel，异步的UDP连接。

NioSctpChannel，异步的客户端Sctp连接。

NioSctpServerChannel，异步的Sctp服务器端连接这些通道涵盖了UDP和TCP网络IO以及文件IO。

EventLoop（事件循环）接口是Netty的核心接口，用于处理连接的生命周期中所发生的各种事件，实际上就是负责监听网络事件并调用事件处理器进行相关I/O操作的处理。

EventLoop内部持有NIO中的Selector，Channel将会注册到EventLoop中，一个EventLoop可以监听多个Channel，EventLoop是实现IO多路复用的核心，可以看作是Reactor模型中的mainReactor。

Channel为Netty网络操作抽象类，EventLoop负责监听注册到其上的Channel的IO事件，两者配合完成I/O操作。

在Netty中所有的IO操作都是异步的，不能立刻得知消息是否被正确处理。

Channel会注册到EventLoop中后会立即返回一个ChannelFuture对象，可以通过ChannelFuture#addListener注册GenericFutureListener监听器，当操作执行成功或失败时监听会自动触发注册的监听事件。

ChannelHandler是消息的具体处理器。 他负责处理各种任务，这个任务非常广泛，可以是读写事件、连接、解码编码、数据转换、业务逻辑等等，处理完毕之后将数据继续转发到ChannelPipeline中的下一个ChannelHandler。

通过定制ChannelHandler可对Netty进行扩展。ChannelHandler接口本身并没有提供很多方法，因为这个接口有许多的方法需要实现，为了方便使用，可以继承它的子类：

ChannelInboundHandler用于处理入站I/O事件

ChannelOutboundHandler用于处理出站I/O操作

或者使用以下适配器类，更加方便：

ChannelInboundHandlerAdapter用于处理入站I/O事件

ChannelOutboundHandlerAdapter用于处理出站I/O操作

ChannelDuplexHandler用于处理入站和出站事件

ChannelPipeline是一个ChannelHandler的链表，即ChannelHandler组成的List，提供了一个沿着链传播入站和出站事件流的API。

可以在ChannelPipeline上通过addLast()方法添加一个或者多个ChannelHandler，因为一个数据或者事件可能会被多个Handler处理。 当一个ChannelHandler处理完之后就将数据交给下一个ChannelHandler。

在执行时，入站事件会从链表head往后传递到最后一个入站的handler（ChannelInboundHandler类型），出站事件会从链表tail往前传递到最前一个出站的handler（ChannelOutboundHandler类型），两种类型的handler在执行时互不干扰。 如果Handler同时属于入站、出站Handler，则都会执行一次。

JBoss和Tomcat部署方式的区别

在Web2.0的浪潮中，各种页面技术和框架不断涌现，为服务器端的基础架构提出了更高的稳定性和可扩展性的要求。 近年来，作为开源中间件的全球领导者，JBoss在J2EE应用服务器领域已成为发展最为迅速的应用服务器。 在市场占有率和服务满意度上取得了巨大的成功，丝毫不逊色于其它的非开源竞争对手，如WebSphere、WebLogic、Application Server。 JBoss Web的诸多优越性能，正是其广为流行的原因。 基于Tomcat内核，青胜于蓝Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，技术先进、性能稳定，而且免费，因而深受Java 爱好者的喜爱并得到了部分软件开发商的认可。 其运行时占用的系统资源小，扩展性好，且支持负载平衡与邮件服务等开发应用系统常用的功能。 作为一个小型的轻量级应用服务器，Tomcat在中小型系统和并发访问用户不是很多的场合下被普遍使用，成为目前比较流行的Web 应用服务器。 而JBoss Web采用业界最优的开源Java Web引擎， 将Java社区中下载量最大，用户数最多，标准支持最完备的Tomcat内核作为其Servlet容器引擎，并加以审核和调优。 单纯的Tomcat性能有限，在很多地方表现有欠缺，如活动连接支持、静态内容、大文件和HTTPS等。 除了性能问题，Tomcat的另一大缺点是它是一个受限的集成平台，仅能运行Java应用程序。 企业在使用时Tomcat，往往还需同时部署Apache Web Server以与之整合。 此配置较为繁琐，且不能保证性能的优越性。 JBoss在Tomcat的基础上，对其进行本地化，将Tomcat 以内嵌的方式集成到 JBoss 中。 JBoss Web通过使用APR和Tomcat本地技术的混合模型来解决Tomcat的诸多不足。 混合技术模型从最新的操作系统技术里提供了最好的线程和事件处理。 结果，JBoss Web达到了可扩展性，性能参数匹配甚至超越了本地Apache HTTP服务器或者IIS。 譬如JBoss Web能够提供数据库连接池服务，不仅支持 JSP 等 Java 技术，同时还支持其他 Web 技术的集成，譬如 PHP、 两大阵营。 标准化是减小技术依赖风险，保护投资最好的方式。 JBoss Web率先支持全系列JEE Web标准，从根本上保证了应用“一次开发，到处运行”的特点，使应用成品能方便地在JBoss Web和其他Java Web服务器之间轻易迁移。 集多功能于一身，性能卓越作为Web 应用服务器中的明星产品，JBoss Web服务器集多种功能于一身。 其关键功能包括：完全支持Java EE、高度的扩展性、快速的静态内容处理、群集、OpenSSL、URL重写和综合性。 JBoss Web服务器具有原生特性和强大的可扩展性，可支持多种并非基于Java的服务器内容处理技术，可同时运行JSP, Servlet, Microsoft , PHP 及 CGI，为其提供一个单一的、高性能的企业级部署平台。 与Tomcat 相比，JBoss Web在静态资源访问方面性能优越。 JBoss Web支持两种组件模式——纯Java和Native I/O。 在Native组件的支持下，动态运行不会受到任何影响，而静态资源的访问利用了操作系统本身提供的0拷贝传送，CPU消耗降低，响应时间缩短，吞吐率大大提高，混合的连接模式支持最大达到个并发客户端的同时访问，与Apache Web服务器相当。 部署于高性能的操作系统，可利用JBoss Web对纯Java和Native I/O两种模式的支持，使得应用在开发时可随时跨平台敏捷迁移，而部署于高性能的操作系统相关的Native环境。 由于JBoss Web较好地解决了静态资源的访问性能问题，可在解决方案中把它直接作为强大的LVS的分发对象，和RHEL负载均衡系统结合，形成理论上无限线性扩展的负载均衡场景。 OpenSSL是业界最为快速和安全的开源传输组件，可借助操作系统和硬件的特性实现高效的安全承载。 JBoss Web集成了OpenSSL，可提供高效的安全传输服务，使得安全机制更上台阶。 研究表明， JBoss Web中的SSL性能比单纯的Tomcat快四倍。 URL重写功能可缩短URL，隐藏实际路径提高安全性，易于用户记忆和键入，及被搜索引擎收录。 Tomcat 不具备URL重写功能，JBoss Web则可提供一个灵活的URL rewriting操作引擎，支持无限个规则数和规则条件。 URL可被重写以支持遗留的URL错误处理，或应对服务器不时产生的其他问题。 JBoss Web既可单独运行，也可无缝嵌入JBoss应用服务器，成为JBoss中间件平台的一部分。 不仅后台服务调用的性能将得以提升，也可利用以下JBoss平台的特性提升Web应用功能：基于JGroups的多种集群方案的支持基于Arjuna技术的JTA和JTS的事务处理支持优化的线程池和连接池的支持基于JMX 控制台的基本管理支持和JBoss On的高级管理维护支持基于JBoss AOP技术的面向方面架构的支持Hibernate服务组件的支持专业团队支持业界大多数开源产品在技术方面富于创新性，但在可持续性，产品生命周期规划，以及质量保证方面缺乏有效保障，为软件集成商和最终用户所诟病。 红帽所力行的“专业化开源技术”则完美解决了这一问题。 来自开源社区的JBoss Web，在红帽专业化开源的锤炼下，在性能、扩展性、稳定性、安全性等方面，已成为一个达到企业级，甚至电信级标准的优秀产品。 红帽不仅有专职的技术团队投入JBoss Web的开发，而且具备专门的QA团队为产品作质量保证。 完善的集成测试和兼容性测试保证了JBoss Web自身的稳定性，并保证了它的后向兼容和其他JBoss产品协作良好的互操作性。 在服务体系保障方面，JBoss 开拓了以产品专家提供的专家级支持服务作为开源软件强大后盾的软件生态模式。 公司以及庞大的 JBoss 授权服务合作伙伴网络可为包括JBoss Web在内的整个JEMS 产品套件提供全面的支持服务。 与Tomcat相比，JBoss Web 可提供迁移服务与现场专家服务，在迁移服务方面，专家指导应用可从Tomcat向JBoss Web迁移，省时省力。 独特的服务订阅模式，全力保障软件生命周期，让企业高枕无忧。

业务常见error示例——并发工具类库导致的线程安全问题

通常提到线程安全问题等就有可能听到关线程安全和并发工具的一些片面的观点和结论。 比如“把 HashMap 改为 ConcurrentHashMap，就可以解决并发问题了呀”“要不我们试试无锁的 CopyOnWriteArrayList 吧，性能更好”。 的确，为了方便开发者进行多线程编程，现代编程语言会提供各种并发工具类。 但如果我们没有充分了解它们的使用场景、解决的问题，以及最佳实践的话，盲目使用就可能会导致一些坑，小则损失性能，大则无法确保多线程情况下业务逻辑正确性。

之前有业务同学和我反馈，在生产上遇到一个诡异的问题，有时获取到的用户信息是别人的。 查看代码后，我发现他使用了ThreadLocal 来缓存获取到的用户信息。 我们知道，ThreadLocal 适用于变量在线程间隔离，而在方法或类间共享的场景。 如果用户信息的获取比较昂贵（比如从数据库查询用户信息），那么在 ThreadLocal 中缓存数据是比较合适的做法。 但，这么做为什么会出现用户信息错乱的 Bug 呢？

使用 Spring Boot 创建一个 Web 应用程序，使用 ThreadLocal 存放一个 Integer 的值，来暂且代表需要在线程中保存的用户信息，这个值初始是 null。 在业务逻辑中，我先从 ThreadLocal 获取一次值，然后把外部传入的参数设置到 ThreadLocal 中，来模拟从当前上下文获取到用户信息的逻辑，随后再获取一次值，最后输出两次获得的值和线程名称。