关于Java程序服务预热那些事

开发 前端
所谓服务预热,就是在服务启动完成到对外提供服务之前,针对特定场景提供一些初始化准备操作。比如线程池预热、缓存预热、数据库预热、web预热和JVM预热等。

一、背景

1.1 什么是服务预热

所谓服务预热,就是在服务启动完成到对外提供服务之前,针对特定场景提供一些初始化准备操作。

比如线程池预热、缓存预热、数据库预热、web预热和JVM预热等。

1.2 为什么要预热

因为服务刚启动的时候需要一段磨合期,这段期间,服务运行状态没有达到最佳。因此,如果这时候一下子将服务流量提升到正常水平,就有可能导致大量请求超时或者瞬间将系统压垮。

针对 Web 应用的场景,将Java程序启动分为两个过程:

1、启动过程:是指从JVM 启动到程序初始化完成能响应第一个请求的阶段。由于启动时需要动态类加载和程序启动时的初始化,导致启动会比较慢。启动慢会影响程序的响应度,减慢 Web 应用扩容。

2、预热过程:是指从JVM 启动到程序优化完成、达到性能峰值的阶段。预热慢会导致 Web 应用无法及时的处理完用户请求,造成大量请求超时。

图片图片

二、如何预热

2.1 预热缓存

a.连接池预热

和数据库连接池一样,我们可以在应用启动时,根据需要初始化若干连接放入连接池,从而避免请求过来的时候再创建而影响性能。

系统启动时,尝试获取若干连接(这里取最小闲置),此时连接池为空,生成连接后会放入连接池,等请求进来的时候就不会再去创建连接了。

图片图片

b.热点数据预热

  • 数据存到redis中

处理方案:

1、配置一个定时任务,刷新缓存数据。

2、直接写个缓存刷新页面,上线后手动刷新。

  • 数据存到本地

对于一些访问度特别高的热点数据,在极端情况下,考虑到服务到redis有网络延迟以及序列化和反序列化消耗,所以放入redis缓存是不太理想的。

那么对于这些数据我们可以考虑放入本地缓存,当然这些数据量不能太大。对于极端的热点数据放入本地缓存后,请求获取数据在应用维度基本没有任何消耗,没有网络延迟也没有序列化和反序列化消耗。

可以使用guava 的cache

2.2 预热线程池

1)请求接收线程池

以tomcat为例,我们可以配置初始化创建线程的数量来做线程池预热。

图片

2)自定义线程池

对于自定义线程池,初始化时候调用prestartAllCoreThreads方法即可。

图片

3)预热DB连接池

服务启动时根据需要创建若干数据库连接,放到连接池中,然后应用启动处理数据库读写请求时,可以直接从连接池中拿连接来用,避免了读写请求创建连接并放入连接池的流程耗时。

我们常用的连接池Druid提供了比较方便的连接池预热能力。常见的配置方式:

图片

4)JVM预热

大家都知道,Java语言是解释执行和编译执行共同存在的。即Java源代码文件(.java)首先由Javac编译为字节码(.class),然后字节码由各操作系统对应的虚拟机解释或编译执行。

为了提高执行速度,引入了JIT(Just-in-time compilation)。在运行时,JIT会把编译过来的机器码保存起来,以便下次使用。JIT只会对经常执行的热点代码进行编译,如循环,高频度使用的方法等。

JVM默认开启JIT编译,可以检查启动参数-Xint和-Djava.compiler=NONE,如果有说明关闭了JIT,根据需要可以移除重新开启JIT。

此外,JDK1.8引入了Lambda表达式,给开发人员带来了很多方便,但是过度的使用Lambda表达式也会带来负面效果。lambda表达式的原理是在执行时生成匿名内部类,并且需要加载和编译。

所以对于一些热点代码可以选择不使用Lambda表达式,或者在服务启动时进行预调用,经过充分的调用之后使其成为热点代码,后续的调用就会走JIT编译,就会跳过生成匿名内部类、加载的步骤,也就提升了执行效率。

三、预热的问题及解决

3.1 时长

既然在服务启动阶段加入了预热逻辑,就会产生损耗,最直接的体现就是服务启动时间变长,可能几分钟到十几分钟不等。

但启动慢不一定就是坏事,相当于是在对外提供服务之前做了充足的初始化以及预热准备。

当然事情都有两面性,关键的是要在启动快与慢之间找到一个平衡点,在保证服务能够在可接受的时间内启动,并且上线之后短时间内就能提供高质量的服务。

3.2 CPU升高

在实际应用过程中,遇到了CPU突增的情况。如下图,服务在启动时会收到CPU报警,查看监控发现CPU使用率是平时的2倍以上。

图片图片

查看启动时的预热代码,发现会触发下面的请求,如图,请求量是平时正常水平的几百倍。因此定位应该是预热代码的问题。

图片图片

预热代码如下:

图片图片

图片图片

上述代码使用CountDownLatch作为计数器,在服务启动时,触发三个热点接口,以达到预热的目的。但是由于参数过多导致服务的请求激增,引发报警。

问题定位之后,我们降低了入参数量,减少了循环次数,从而减少了服务自请求次数,问题得以修复。

四、总结

以上是服务预热的一些常见方式,服务预热是把双刃剑,在使用之前,需要搞清楚哪些服务需要预热。对于需要预热的服务,需要搞清楚具体需要预热哪些内容,不能盲目预热,容易适得其反。

责任编辑:武晓燕 来源: 架构精进之路
相关推荐

2012-05-01 08:06:49

手机

2015-08-19 09:10:37

程序员面试

2012-01-02 19:30:22

iPad

2011-08-22 16:42:43

SqliteiPad

2015-07-23 13:10:38

服务器虚拟化

2022-05-06 07:52:06

Nacos服务注册

2021-05-17 08:18:35

Java内存模型JMM

2011-08-01 17:31:25

Xcode开发 Cocoa

2012-07-13 00:03:08

WEB前端开发WEB开发

2011-07-04 13:51:02

QT 对象 模型

2019-12-10 08:00:46

Kata容器Linux

2015-09-14 09:28:47

2011-07-19 15:33:57

iPhone

2011-06-30 10:59:43

2009-02-19 10:21:00

路由多WAN口

2015-08-13 10:54:46

2021-03-18 16:05:20

SSD存储故障

2022-09-09 08:08:28

开源项目服务

2019-01-04 10:53:59

CPUCache缓存

2012-05-01 21:27:55

图标
点赞
收藏

51CTO技术栈公众号