在之前的项目中,多数据源路由曾采用在接口上使用自定义注解指定数据源的方式实现。直到前几天,有同事反馈使用了自定义注解但是数据源切换没有生效,经过排查后,确认是多接口存在相同方法导致,简化后的部分代码如下,原 DAO 接口定义为:
1 | public interface BizDao { |
而后同事新写了个 DAO 接口并继承了 BizDao,简化后的代码如下:
1 |
|
在之前的项目中,多数据源路由曾采用在接口上使用自定义注解指定数据源的方式实现。直到前几天,有同事反馈使用了自定义注解但是数据源切换没有生效,经过排查后,确认是多接口存在相同方法导致,简化后的部分代码如下,原 DAO 接口定义为:
1 | public interface BizDao { |
而后同事新写了个 DAO 接口并继承了 BizDao,简化后的代码如下:
1 | @DataSource(Database.ANALYTIC) |
GC 日志:
1 | 2022-01-17T13:39:14.399+0800: 920001.780: [GC pause (G1 Evacuation Pause) (young), 0.0109317 secs] |
OperatingSystemMXBean 中的 getFreePhysicalMemorySize() 方法返回的值为不含缓存的可用物理内存,该指标不能很好的反应 Linux 中实际可用的物理内存,因为 Linux 尽量使用内存的特性,该指标返回的数据几乎总是接近总物理内存,我们根据 /proc/meminfo 中返回的数据采集出类似 free 命令中 available 列的值以便更好的监测可用物理内存。
同事反馈有一组应用的定时任务不执行了,简单看了下,该应用未定义过基于 TaskScheduler 或 ScheduledExecutorService 实现的 Bean,此时 Spring 会在 ScheduledTaskRegistrar.scheduleTasks() 中创建一个单线程的任务调度器:
1 | /** |
前段时间有线上实例被负载均衡判定不可用,随即被摘除,同时我们收到该实例的 JVM GC 耗时较长的告警及负载较高的告警。从操作系统级别的监控可以看到磁盘读取速度几乎达到该规格的上限,近 120MB/s,IOPS 为 2200 左右,使用 ssh 登录该实例需要等待很久,且进入实例后几乎无法输入命令,2 核的机器负载达到了 20 左右。持续了七八分钟会恢复正常,恢复正常后我首先查看了 GC 日志,确认是否存在大量 FullGC,但是从日志中并未发现长时间的 Full GC,普通的 GC 的 real 耗时都很久,部分 GC 日志如下: