本文分以下几点：

1. Eureka的高可用实现
   a. eureka客户端与服务端通讯机制
   b. eureka服务端与其他服务节点的通讯
   c. eureka服务端的自我保护机制
2. Eureka与ZK的比较
   a. CAP模型
   b. 使用场景

Eureka高可用实现

Eureka的高可用通过以下三点实现：
a. eureka客户端与服务端通讯机制
b. eureka服务端与其他服务节点的通讯
c. eureka服务端的自我保护机制

eureka客户端与服务端通讯机制

可以看下客户端与Eureka服务端之间的通讯的概述流程：

同时为了更好的说明高可用的实现，在这里大概描述一下Eureka服务端的存储结构：

服务注册

1. 客户端请求POST /eureka/v2/apps接口，将客户端的服务信息上传
   PeerAwareInstanceRegistryImpl.java 399行：

   1 2 3 4 5 6 7 8

   int leaseDuration = Lease.DEFAULT_DURATION_IN_SECS; if (info.getLeaseInfo() != null && info.getLeaseInfo().getDurationInSecs() > 0) { leaseDuration = info.getLeaseInfo().getDurationInSecs(); } // 本地注册 super.register(info, leaseDuration, isReplication); // 协同其他eureka服务节点同步注册 replicateToPeers(Action.Register, info.getAppName(), info.getId(), info, null, isReplication);

2. Eureka服务端将客户端信息保存至Registry注册信息载体内

3. 将此次添加变更增加到变更队列
   AbstractInstanceRegistry.java 194行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

   public void register(InstanceInfo registrant, int leaseDuration, boolean isReplication) { try { // 读锁 read.lock(); // 存储本次注册信息（appName -> instanceId -> instanceInfo） Map<String, Lease<InstanceInfo>> gMap = registry.get(registrant.getAppName()); REGISTER.increment(isReplication); if (gMap == null) { final ConcurrentHashMap<String, Lease<InstanceInfo>> gNewMap = new ConcurrentHashMap<String, Lease<InstanceInfo>>(); gMap = registry.putIfAbsent(registrant.getAppName(), gNewMap); if (gMap == null) { gMap = gNewMap; } } // ...其他逻辑 // 将本次添加变更加入最近变更队列内 recentlyChangedQueue.add(new RecentlyChangedItem(lease)); // 设置租约的上一次更新时间 registrant.setLastUpdatedTimestamp(); // 执行缓存清空 invalidateCache(registrant.getAppName(), registrant.getVIPAddress(), registrant.getSecureVipAddress()); } finally { // 读锁解锁 read.unlock(); } }

4. 清空读写缓存（先清理APP、再清理ALL_APPS、最后清理ALL_APPS_DELTA）
   ResponseCacheImpl.java 251行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

   public void invalidate(String appName, @Nullable String vipAddress, @Nullable String secureVipAddress) { for (Key.KeyType type : Key.KeyType.values()) { for (Version v : Version.values()) { // 删除appName本身的缓存 // 删除ALL_APPS的缓存 // 删除ALL_APPS_DELTA的缓存 invalidate( new Key(Key.EntityType.Application, appName, type, v, EurekaAccept.full), new Key(Key.EntityType.Application, appName, type, v, EurekaAccept.compact), new Key(Key.EntityType.Application, ALL_APPS, type, v, EurekaAccept.full), new Key(Key.EntityType.Application, ALL_APPS, type, v, EurekaAccept.compact), new Key(Key.EntityType.Application, ALL_APPS_DELTA, type, v, EurekaAccept.full), new Key(Key.EntityType.Application, ALL_APPS_DELTA, type, v, EurekaAccept.compact) ); // 存在虚拟地址名称的，删除虚拟地址为key的缓存 if (null != vipAddress) { invalidate(new Key(Key.EntityType.VIP, vipAddress, type, v, EurekaAccept.full)); } // 存在安全虚拟地址名称的，删除安全虚拟地址为key的缓存 if (null != secureVipAddress) { invalidate(new Key(Key.EntityType.SVIP, secureVipAddress, type, v, EurekaAccept.full)); } } } }

ResponseCacheImpl.java 277行：

1
2
3
4
5
6
7
8
9

public void invalidate(Key... keys) {
    for (Key key : keys) {
        // Guava缓存对key设置无效
        readWriteCacheMap.invalidate(key);
        Collection<Key> keysWithRegions = regionSpecificKeys.get(key);
        // key关联区域的缓存无效设置
        // ...
    }
}

5. 判断不存存在其他eureka服务节点，或者本次请求为同步请求则完成注册
   PeerAwareInstanceRegistryImpl.java 620行：

   1 2 3

   if (peerEurekaNodes == Collections.EMPTY_LIST || isReplication) { return; }

6. 否则，获取所有其他的服务节点，排除本身服务，将本次注册同步至其他eureka服务节点
   PeerAwareInstanceRegistryImpl.java 624行：

   1 2 3 4 5 6 7 8

   for (final PeerEurekaNode node : peerEurekaNodes.getPeerEurekaNodes()) { // 排除自身 if (peerEurekaNodes.isThisMyUrl(node.getServiceUrl())) { continue; } // 同步其他服务节点 replicateInstanceActionsToPeers(action, appName, id, info, newStatus, node); }

服务续约

1. 客户端请求PUT /eureka/v2/apps/{appId}
2. 根据appName获取租约
3. 更新租约
4. 同步至其他eureka服务节点

续约类似心跳机制，客户端会按照默认时间的30秒定时做一次续约，如果超过3次没有成功，则服务端会将该客户端剔除。

服务取消注册

1. 客户端请求DELETE /eureka/v2/apps/{appId}
2. 根据appName获取租约
3. 设置租约过期时间evictionTimestamp为当前时间
4. 将此次删除增加到变更队列中
5. 清空读写缓存（先清理APP、再清理ALL_APPS、最后清理ALL_APPS_DELTA）

服务剔除

1. Eureka服务端会在内部会初始化一个Timer定时器用于定时调度处理剔除任务；剔除时间间隔为evictionIntervalTimerInMs
AbstractInstanceRegistry.java 1212行：

   1 2 3 4 5 6 7 8 9

   protected void postInit() { // .... // 设置新的过期任务 evictionTaskRef.set(new EvictionTask()); // 任务调度 evictionTimer.schedule(evictionTaskRef.get(), serverConfig.getEvictionIntervalTimerInMs(), serverConfig.getEvictionIntervalTimerInMs()); }

2. 判断是否启用自我保护，如果禁用，则不进行服务剔除

3. 判断 上一分钟实际的续约次数 <= numberOfRenewsPerMinThreshold，则会触发自我保护机制，停止服务剔除
   PeerAwareInstanceRegistryImpl.java 474行：

   1 2 3 4 5 6

   // 判断自我保护是否禁用 if (!isSelfPreservationModeEnabled()) { return true; } // 自我保护机制阈值判断 return numberOfRenewsPerMinThreshold > 0 && getNumOfRenewsInLastMin() > numberOfRenewsPerMinThreshold;

4. 遍历Registry内所有的租约信息，判断当前租约是否过期

5. 将这些过期的租约放置到一个过期列表内
   AbstractInstanceRegistry.java 597行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   List<Lease<InstanceInfo>> expiredLeases = new ArrayList<>(); // 遍历租约 for (Entry<String, Map<String, Lease<InstanceInfo>>> groupEntry : registry.entrySet()) { Map<String, Lease<InstanceInfo>> leaseMap = groupEntry.getValue(); if (leaseMap != null) { for (Entry<String, Lease<InstanceInfo>> leaseEntry : leaseMap.entrySet()) { Lease<InstanceInfo> lease = leaseEntry.getValue(); // 判断租约是否过期 // additionalLeaseMs是补偿时间，防止由于GC或者本地时间造成的一个时间误差，确保能够按照预期时间执行 if (lease.isExpired(additionalLeaseMs) && lease.getHolder() != null) { // 将过期租约加入过期列表 expiredLeases.add(lease); } } } }

6. 计算可被剔除的过期实例数（过期数 = Math.min(过期列表大小, (本地租约数 - 本地租约数 * 续约百分比))）
   AbstractInstanceRegistry.java 612行：

   1 2 3 4 5 6

   // 获取本地租约数 int registrySize = (int) getLocalRegistrySize(); // 计算租约 int registrySizeThreshold = (int) (registrySize * serverConfig.getRenewalPercentThreshold()); // 实际需要剔除的租约个数 int evictionLimit = registrySize - registrySizeThreshold;

7. 使用洗牌算法找出需要剔除的n个实例
   AbstractInstanceRegistry.java 620行：

   1 2 3 4 5 6 7 8

   // 按照剔除数遍历，每次的交换对象都是基于上次的随机结果 Random random = new Random(System.currentTimeMillis()); for (int i = 0; i < toEvict; i++) { // 筛选出需要交换位置的索引next并与i交换位置 int next = i + random.nextInt(expiredLeases.size() - i); Collections.swap(expiredLeases, i, next); // 剔除逻辑 }

8. 设置租约过期时间evictionTimestamp为当前时间

9. 将此次删除增加到变更队列中
10. 清空读写缓存

eureka服务端与其他服务节点的通讯

eureka服务端与其他服务节点的通讯主要包含两部分：

1. eureka服务端启动时候自动拉取其他服务节点的注册信息并落入本地Registry中
2. 一旦有诸如register,renew,cancel请求，则会将这些请求通过线程池自动同步至其他服务节点

启动初始化

1. Servlet容器初始化，调用eureka环境初始化以及eureka上下文初始化
   EurekaBootstrap.java 111行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14

   public void contextInitialized(ServletContextEvent event) { try { // 初始化环境 initEurekaEnvironment(); // 初始化上下文 initEurekaServerContext(); ServletContext sc = event.getServletContext(); sc.setAttribute(EurekaServerContext.class.getName(), serverContext); } catch (Throwable e) { logger.error("Cannot bootstrap eureka server :", e); throw new RuntimeException("Cannot bootstrap eureka server :", e); } }

2. 初始化上下文的过程中会开始同步其他eureka服务节点的信息
   EurekaBootstrap.java 147行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

   protected void initEurekaServerContext() throws Exception { // ...其他逻辑 ApplicationInfoManager applicationInfoManager = null; // 初始化eureka客户端，用于做为获取其他eureka服务信息的client if (eurekaClient == null) { EurekaInstanceConfig instanceConfig = isCloud(ConfigurationManager.getDeploymentContext()) ? new CloudInstanceConfig() : new MyDataCenterInstanceConfig(); applicationInfoManager = new ApplicationInfoManager( instanceConfig, new EurekaConfigBasedInstanceInfoProvider(instanceConfig).get()); EurekaClientConfig eurekaClientConfig = new DefaultEurekaClientConfig(); eurekaClient = new DiscoveryClient(applicationInfoManager, eurekaClientConfig); } else { applicationInfoManager = eurekaClient.getApplicationInfoManager(); } // 初始化其他服务实例感知的注册器 PeerAwareInstanceRegistry registry; if (isAws(applicationInfoManager.getInfo())) { // aws 服务 // ... } else { registry = new PeerAwareInstanceRegistryImpl( eurekaServerConfig, eurekaClient.getEurekaClientConfig(), serverCodecs, eurekaClient ); } // 为其他eureka服务注册eurekaNode实例 PeerEurekaNodes peerEurekaNodes = getPeerEurekaNodes( registry, eurekaServerConfig, eurekaClient.getEurekaClientConfig(), serverCodecs, applicationInfoManager ); // servlet容器初始化 // ... // 从其他服务拷贝注册信息 int registryCount = registry.syncUp(); // 等待接收请求 registry.openForTraffic(applicationInfoManager, registryCount); // 其他操作 // ... }

同步逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public int syncUp() {
    int count = 0;

    // 尝试同步直到达到最大尝试次数
    for (int i = 0; ((i < serverConfig.getRegistrySyncRetries()) && (count == 0)); i++) {
        if (i > 0) {
            // 尝试间隔睡眠时间
            // ...
        }
        // 获取所有的应用
        Applications apps = eurekaClient.getApplications();
        // 获取所有注册的应用
        for (Application app : apps.getRegisteredApplications()) {
            for (InstanceInfo instance : app.getInstances()) {
                try {
                    // 判断应用是否在当前区域注册
                    // 该配置只对于AWS有效，其他非AWS服务全部会拉取
                    if (isRegisterable(instance)) {
                        // 是，则落入本地内存
                        register(instance, instance.getLeaseInfo().getDurationInSecs(), true);
                        count++;
                    }
                } catch (Throwable t) {
                    logger.error("During DS init copy", t);
                }
            }
        }
    }
    return count;
}

3. 完成后开始接收请求

过程中同步

以注册同步为例子。

1. 根据请求类型判断执行动作
   PeerAwareInstanceRegistry.java 648行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   case Cancel: node.cancel(appName, id); break; case Heartbeat: InstanceStatus overriddenStatus = overriddenInstanceStatusMap.get(id); infoFromRegistry = getInstanceByAppAndId(appName, id, false); node.heartbeat(appName, id, infoFromRegistry, overriddenStatus, false); break; case Register: // 调用PeerEurekaNode的register方法执行注册动作的同步 node.register(info); break; case StatusUpdate: infoFromRegistry = getInstanceByAppAndId(appName, id, false); node.statusUpdate(appName, id, newStatus, infoFromRegistry); break; case DeleteStatusOverride: infoFromRegistry = getInstanceByAppAndId(appName, id, false); node.deleteStatusOverride(appName, id, infoFromRegistry); break;

2. 将任务提交至任务处理器TaskDispatcher进行
   PeerEurekaNode.java 135行：

   1 2 3 4 5 6 7 8 9 10 11

   long expiryTime = System.currentTimeMillis() + getLeaseRenewalOf(info); batchingDispatcher.process( taskId("register", info), // 同步任务信息 new InstanceReplicationTask(targetHost, Action.Register, info, null, true) { public EurekaHttpResponse<Void> execute() { return replicationClient.register(info); } }, expiryTime );

3. 调用Jersey2执行REST请求
   AbstractJersey2EurekaHttpClient.java 85行：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

   public EurekaHttpResponse<Void> register(InstanceInfo info) { String urlPath = "apps/" + info.getAppName(); Response response = null; try { // 封装请求 Builder resourceBuilder = jerseyClient.target(serviceUrl).path(urlPath).request(); addExtraProperties(resourceBuilder); // 设置x-netflix-discovery-replication头信息为true，其他eureka服务节点接收后会知晓这是个同步请求 addExtraHeaders(resourceBuilder); // 执行请求并获取结果 response = resourceBuilder .accept(MediaType.APPLICATION_JSON) .acceptEncoding("gzip") .post(Entity.json(info)); return anEurekaHttpResponse(response.getStatus()).headers(headersOf(response)).build(); } finally { if (logger.isDebugEnabled()) { logger.debug("Jersey2 HTTP POST {}/{} with instance {}; statusCode={}", serviceUrl, urlPath, info.getId(), response == null ? "N/A" : response.getStatus()); } if (response != null) { response.close(); } } }

Eureka自我保护机制

Eureka是Netflix为了解决现有AWS的注册服务无法解决的一些场景而专门研发的。在设计之初，就考虑到高可用特性，防止AWS突然性的大规模断点造成服务不可用的情况设计了Eureka的自我保护机制。

Eureka的自我保护机制设定为：服务总数 每分钟续约数（60s / 客户端续约间隔） 自我保护阈值因子

举个例子说明：
如果某个应用A有100个服务实例，那么按照公式计算，它在一分钟内续约次数必须 >= 170。

如果在上一个分钟内，续约数 > 170，那么服务正常，某个实例就算失败也只会认为是客户端存在问题，会被剔除；
如果在上一个分钟内，续约数 < 170，那么Eureka就会认为是Eureka服务存在问题，会停止剔除流程，保护现有的注册信息，防止服务大规模下线。

Eureka与ZK的比较

CAP模型

Eureka是AP模型，ZK是CP模型。前者强调高可用，即使在某些情况下不同region看到的视图可能不一致；而后者强调的是强一致性，且在超过一定阈值后会造成ZK集群整体不可用

应用场景

这几年工作学习下来，对于开源框架分析学习没有一个完善的方法论可供参考，结合自身的学习经验，在这里略微发表下笔者的思路。

指导思想

1. 首先需要了解这个开源框架的框架性功能（如果文档没有，则通过这个框架的具体功能来提取要素，找到框架性功能）
2. 分析不同框架性功能在这个框架内的作用（核心功能、支撑功能）
3. 对于核心功能具体分析，对于支撑功能有兴趣再了解
4. 核心功能分析，按照上述2、3的逻辑再做具体功能的拆分，基本上拆出这两层已经差不多
5. 画出核心功能的依赖处理流程图
6. 查看每个功能的核心类，搞清楚不同功能的核心类的交互机制以及如何构建出这个框架的核心能力，输出核心流程图（时序图也可）
7. 从核心类出发，查看其它支撑类的作用，并构建类图
8. 从底往上出发，查看框架应用的设计模式以及为何需要使用这个设计模式，对于扩展性、易用性、可读性等的影响在哪里
9. 总结性文档输出

系统设计的整体方法论学习与尝试

方法论

系统设计的目的 -> 系统设计的目标 -> 围绕目标的核心设计 -> 围绕核心设计形成的设计原则 -> 各子系统

系统设计的目的

• 设计一个易用、高可用、可支持大规模访问的短域名系统

系统设计的目标

• 支持短域名领域TOP5的网站规模
• 支持99%的可用性
• 响应时间在100ms以内
• 域名长度限制在10个字符以内

围绕目标的核心设计

对上述系统目标做技术性的一个拆分

• 支持短域名领域TOP5的网站规模
  • 全球排名第二的Youtube月访问量：284.4亿（近6个月PV数据量） * 9.56 / 6 = 453.144亿
  • 按照二八原则，TOP5的月流量大概在90.63亿次
  • 假设15%的请求访问到短域名生成服务，生成短域名月访问量级别在13.59亿次
  • 假设30%的请求访问到短域名生成的短连接上，短域名转化服务月访问量级别在27.19亿
  • 生成短域名服务按照域名存储的量级计算
    • 假设按最长长度存储，即10字符，需要月存储的key量级在10 4 13.59亿 / 1024 / 1024 / 1024 = 50.63GB；年存储量级607.52GB
    • 假设转发网址长度平均在100字符，需要月存储的value量级在10 * 50.63GB = 506.3GB；年存储级6075.6GB
• 支持99.9%的可用性
  • 自然年内服务中断时长不能超过8.76小时
• 响应时间在100ms以内
  • 生成短域名请求为13.59亿次/月，TPS大概为525
  • 短域名代理跳转请求为27.19亿次/月，QPS大概为1049
• 域名长度限制在10个字符以内
  • 目前互联网存在40.1M个网站
  • 10个字符按照大小写数字计算62^10 >> 40.1M

各子系统

根据单一职责设计原则，划分子系统：

1. 短域名生成服务：将长链接转为短连接
2. 短域名代理服务：根据短连接302跳转至目标地址

具体设计

围绕上述的核心设计，可以预知的挑战主要有如下几点：

1. 5年内hash存储量级在3TB，原始url信息存储量级在30TB左右
2. 每秒总请求 1600 左右
3. 99.9%的可用性

接下来对于3个预知的挑战点做具体的分析探讨

存储问题

在不进行任何转化算法以及数据压缩之前，数据的存储量级是非常大的。
这会造成两个影响：

1. 无法快速索引，即使使用KV数据库，也需要找到这个KEY的位置
2. 过于庞大的数据库对于磁盘存在一定的水平扩展压力

所以，需要从以下几个点考虑上述两个问题：

1. 如何构建快速查询的索引结构，尽可能在较少的时间复杂度下获取结果
   • 现有的不管是关系型数据库MySQL，还是NoSQL类型的MongoDB、HBase等，对于键的查询还是比较快的，时间复杂度在O(logn)级别。
     所以在索引查询上，可以直接使用现有的存储数据库。
2. 如何处理数据存储的压缩，减少存储的压力
   • 在数据存储层面可以考虑使用变长字段，而不是固长字段减少数据占用
3. 如何在磁盘容量不足的情况下，达到平滑扩容的效果，而不会影响现有的系统
   • 使用现成的可扩容数据存储来实现效果
   • 自己实现分布式存储，使用一致性hash算法来分发；但是如果新增了一个物理存储节点，需要进行数据重新分配操作

高并发问题

每秒总请求1600左右，其中写请求525，读请求1049；可以确认是读多写少的业务场景，可以从以下四个方面优化：

1. 减少上游请求数
   • 使用布隆过滤器，不存在的必定不存在
     • 按照5年hash存储记录数来计算，需要存储480亿的key
     • 布隆过滤器1%误差率，一个key大概需要9.6bits空间，480亿的key大概需要53GB的内存量
2. 路由分发，且对应读服务做缓存保证
   • 在网关层将key做一层hash，分散到一致性hash环上
   • 每个短域名代理转发服务器，都有一个LRU的本地缓存
3. 抽离热点数据，对不同key的访问做分值统计，高分值数据到达一个阈值存入集中式缓存
   • 短域名代理转发服务器启动的时候预加载热点数据至本地缓存
   • 访问完成的时候，如果某个key达到一个阈值后，则异步将该值存入本地缓存，并广播完成后，存入至集中式缓存内；存储失败则最多3次重试
4. 存储层面读写分离

高可用问题

可用性主要体现在以下几个方面：

1. 服务的可用性
   • 注册中心本身使用多节点主备策略，保证自身高可用
   • 注册中心维护服务的负载均衡，服务调用通过注册中心调用目标服务器，可以选择负载均衡策略为WeightedResponseTimeRule
2. 数据存储可用性
   • 主从备份机制
3. 数据本身可用性
   • 异机replica机制，保证数据的可恢复性

一直想要自己做出一个操作系统，因此对于现有linux需要有个详细的了解，知道操作系统如何实现所有的过程。因此，在这篇文章中记录下linux的详细启动过程。

本篇打算从三个部分讲解Linux启动的过程：

1. BIOS阶段
2. BootLoader阶段
3. 内核启动阶段

本文前提：非UEFI模式

BIOS阶段

当计算机启动电源，CPU需要执行第一条指令，这条指令又从何而来？

计算机的内存会将内存划分为多个区，每个区都有不同的功能，甚至直接映射到硬件。如下图为内存划分：

上图中，0xF0000 ~ 0xFFFFF 为ROM区，直接映射为BIOS芯片存储区。当电脑启动的时候，相关的寄存器将会被初始化，这边重点关注段寄存器CS以及指令指针寄存器IP。CS将会重置为0xF000，IP将会重置为0x0000；CS:IP指向的就是第一条指令的地址：0xF0000。而从上图可以知晓，这个地址对应的就是ROM区。

CPU开始执行ROM区的指令，由于这块区域只有16字节的大小，所以不会放置太过复杂的程序，一般只有一条JMP指令；这条指令指向的是低地址空间，并将BIOS程序载入到RAM空间执行。之后开始执行初始化过程，包括中断向量表、中断服务（对于键盘、鼠标等中断信号的响应以及处理）以及硬件健康自检。

如下图描述了整个BIOS启动过程：

上图中的流程需要提一嘴的是在按下【DEL】键的时候，会进行中断处理，解压Setup模块。这个模块是一个BIOS设置引导界面程序，在BIOS设置中可以设置启动介质以及介质的启动顺序、硬件相关的一些配置等等。而由于BIOS芯片是ROM芯片，不存在存储的能力，所以计算机专门准备了一个RAM介质用于存储配置，这个RAM名为CMOS。一般我们经常听到其他人说什么CMOS放电处理，其实就是为了让RAM能够长期保存配置，会有一个专门的电池用于对CMOS供电，这样即便是在计算机断点的情况下，BIOS的设置也不会丢失；而放电的操作，就是让CMOS断电，将配置回复到初始状态。

自此，BIOS阶段结束。

BootLoader阶段

在BIOS在执行完初始化工作后，最终的操作系统又是如何被发现的？

BIOS程序在完成硬件自检之后，就需要查询从启动介质中查询可引导分区了，而引导分区的作用就是用来载入最终的操作系统。

前一节已经讲过CMOS，也知道CMOS用于保存BIOS配置，其中就包括了启动介质的配置以及顺序设置。BIOS程序之后就会按照顺序遍历启动介质，知道发现可引导分区（MBR）；而MBR如何发现呢？在载入每个介质第一个扇区（512字节）后，会将这段内容防止在内存上的0x00000-0x7C00区域，并判断这段内容是否以AA55这两个字节结束；如果是，则该介质为启动介质；否则，继续查看下一个介质。

可以看下下图的MBR的引导分区结构图：

MBR分区主要分为三个块：

1. 代码块：446字节，主要用于存储可执行代码以及错误消息文本
2. 分区表：64字节，每个分区占用16字节，所以MBR最多可以划分4个分区；而为了突破这个限制，MBR将最后一个分区定义为扩展分区，然后在扩展分区内可以划分逻辑分区
3. 结束符：2字节

在找到MBR之后，会加载代码块的代码；这段代码就是BootLoader，即GRUB的最小可执行程序。为什么只装在最小可执行程序，主要原因还是由于MBR的可容纳空间过于小，这段程序会加载完整的GRUB程序。

GRUB

GRUB，GRand Unified Bootloader。它是一个多重操作系统启动管理器，用来引导不同系统，如windows，linux。

在启动BootLoader之后，GRUB最小执行程序（boot.img）会载入MBR分区后的内容（core.img），这些内容由以下四个部分组成：diskboot.img、lzma_decompress.img、kernel.img以及一些模组。如下图：

diskboot.img会解压lzma_decompress.img程序，然后将控制权转交给它。lzma在解压缩kernel.img之前，会将计算机从实模式转化为保护模式（实模式下内存最大寻址为2^20，而保护模式下内存最大寻址为2^32），这样，可以在解压kernel.img后，将其载入至内存空间内执行。

而在切换为保护模式后，计算机会处理如下工作：

1. 启用分段：段寄存器指向段描述符表，用于隔离不同进程
2. 启动分页：将内存分页，方便程序使用以及申请
3. 打开Gate A20开关：在实模式下只有20根地址线，可以访问1M内存空间；所以，在保护模式下，需要打开这个开关，用于访问超过1M空间的内存

之后，将会解析grub的配置文件（/boot/grub/grub.conf），并将其配置显示，用户可以选择其中一个操作系统载入。

在用户选择某个操作系统后，GRUB会检查linux内核头文件信息是否完整和正常，并加载linux内核镜像到内存；最终执行grub_command_execute(“boot”, 0,0)方法启动内核，将控制权交由给内核。

内核启动

加载内核镜像至内存后，linux如何做系统初始化以及启动第一个用户进程？

内核会处理如下事项：

1. 初始化进程栈以及初始化0号进程（该进程是唯一没有fork或者通过kernel_thread产生的进程）
2. 中断门初始化
3. 内存管理初始化
4. 调度系统初始化
5. 虚拟文件系统初始化
6. 1号进程初始化
7. 2号进程初始化

着重对于1号进程以及2号进程的初始化做具体分析

1号进程初始化

在初始完成线程栈、中断门、MMU、VFS后会开始执行创建第二个进程，也就是1号进程；这个进程将会运行第一个用户进程。

它会尝试通过一个初始化文件来执行，不同linux版本可能运行的文件不同：

1. /sbin/init
2. /etc/init
3. /bin/init
4. /bin/sh

执行init文件的过程中，它会处理如下事项？

1. 载入ELF（用于规定程序载入的内存格式）
2. 启动用户线程

自此，1号进程作为所有用户态进程存在

2号进程初始化

在1号进程完成用户线程启动后，rest_init函数还创建了2号进程用于管理所有的内核态进程。

总结

linux启动过程在此告一段落，之后可能会对这个过程做更详细的分析以及说明。

最近在学习Elasticsearch相关的一些原理，然后在映像中ES的text字段如果存在keyword的fields，则会在聚合的时候选择keyword类型进行聚合，同时在文本检索的时候根据text类型分词检索。因此，想探究下这个的实现过程。

ES查询原理

需要了解keyword的选择郭成，需要指定如下两点：

1. 字段在启动过程中如何初始化
2. 查询的时候如何筛选需要的字段以及选择类型

ES初始化流程

通过以下时序图记录下ES初始化过程中的大致过程：

sequenceDiagram;  Elasticsearch->>Command: 主程序入口，解析命令参数  Command->>Command: 注册closeHook，执行主函数前置hook函数beforeMain.run()  Command->>EnvironmentAwareCommand: 执行环境参数初始化  EnvironmentAwareCommand->>Elasticsearch: 执行启动具体命令  Elasticsearch->>Elasticsearch: 参数解析  Elasticsearch->>Bootstrap: 执行初始化静态方法init  Bootstrap->>Bootstrap: 实例化Bootstrap，初始化keepAlive线程  Bootstrap->>Bootstrap: 创建上下文环境，设置环境的日志配置  Bootstrap->>Bootstrap: 创建PID文件  Bootstrap->>Bootstrap: 检查luence版本  Bootstrap->>Bootstrap: 初始化插件进程，初始化节点  Bootstrap->>Bootstrap: 节点启动以及保活线程启动  BootStrap->>Node: 尝试启动节点  Node->>Node: 节点状态更改  Node->>Node: 各服务初始化启动  Node->>Node: Netty服务启动  alt: 当前节点为Master/Data    Node->>Node: 获取GatewayMetaState实例    Node->>GatewayMetaState: 执行loadMetaState载入元信息    GatewayMetaState->>MetaStateService: 执行loadFullState方法载入全局状态以及索引状态    MetaStateService->>MetaStateService: 载入全局状态    MetaStateService->>MetaStateService: 查找所有的索引路径    MetaStateService->>MetaStateService: 解析每个索引路径，载入最新的状态    MetaStateService->>MetaStateService: 将索引状态放入全局状态内缓存  else:    Node->>Node: 创建空的元信息  end  Node->>Node: 启动Discovery服务以及Cluster服务  Node->>Node: 节点Transport服务开始接收请求  Node->>Node: 初始化集群状态，并监听集群状态变更  alt: 启用HTTP模块    Node->>Node: 初始化HTTP服务，并启动  end  alt: 是否将端口信息写入文件    alt: 启用HTTP模块      Node->>Node: 将http端口写入    end    Node->>Node: 将transport端口写入  end  Node->>Node: 集群插件执行onNodeStarted方法进行节点初始化

上述流程大致将ES整个启动流程大概讲述了一遍，具体了解下在加载过程中如何解析数据文件并将其加入缓存。

在上述流程中可以找到如下这一块是重点：

sequenceDiagram;  Node->>Node: 获取GatewayMetaState实例  Node->>GatewayMetaState: 执行loadMetaState载入元信息  GatewayMetaState->>MetaStateService: 执行loadFullState方法载入全局状态以及索引状态  MetaStateService->>MetaStateService: 载入全局状态  MetaStateService->>MetaStateService: 查找所有的索引路径  MetaStateService->>MetaStateService: 解析每个索引路径，载入最新的状态  MetaStateService->>MetaStateService: 将索引状态放入全局状态内缓存

载入每个索引最新的状态代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

public  T loadLatestState(Logger logger, NamedXContentRegistry namedXContentRegistry, Path... dataLocations) throws IOException {
  List<PathAndStateId> files = new ArrayList<>();
  long maxStateId = -1;
  boolean maxStateIdIsLegacy = true;
  if (dataLocations != null) {
      // 对于数据文件位置列表做遍历
      for (Path dataLocation : dataLocations) {
          final Path stateDir = dataLocation.resolve(STATE_DIR_NAME);
          try (DirectoryStream<Path> paths = Files.newDirectoryStream(stateDir)) {
              for (Path stateFile : paths) {
                  // 筛选状态文件
                  final Matcher matcher = stateFilePattern.matcher(stateFile.getFileName().toString());
                  if (matcher.matches()) {
                      final long stateId = Long.parseLong(matcher.group(1));
                      maxStateId = Math.max(maxStateId, stateId);
                      final boolean legacy = MetaDataStateFormat.STATE_FILE_EXTENSION.equals(matcher.group(2)) == false;
                      maxStateIdIsLegacy &= legacy;
                      PathAndStateId pav = new PathAndStateId(stateFile, stateId, legacy);
                      logger.trace("found state file: {}", pav);
                      // 加入文件列表
                      files.add(pav);
                  }
              }
          } catch (NoSuchFileException | FileNotFoundException ex) {
              // no _state directory -- move on
          }
      }
  }
  final List<Throwable> exceptions = new ArrayList<>();
  T state = null;
  // 筛选出最大版本号的最新索引文件
  Collection<PathAndStateId> pathAndStateIds = files
          .stream()
          .filter(new StateIdAndLegacyPredicate(maxStateId, maxStateIdIsLegacy))
          .collect(Collectors.toCollection(ArrayList::new));

  for (PathAndStateId pathAndStateId : pathAndStateIds) {
      try {
          final Path stateFile = pathAndStateId.file;
          final long id = pathAndStateId.id;
          if (pathAndStateId.legacy) {
              // 旧版格式
              final byte[] data = Files.readAllBytes(stateFile);
              if (data.length == 0) {
                  logger.debug("{}: no data for [{}], ignoring...", prefix, stateFile.toAbsolutePath());
                  continue;
              }
              // 解析文件内容
              try (XContentParser parser = XContentHelper.createParser(namedXContentRegistry, new BytesArray(data))) {
                  state = fromXContent(parser);
              }
              if (state == null) {
                  logger.debug("{}: no data for [{}], ignoring...", prefix, stateFile.toAbsolutePath());
              }
          } else {
              // 最新版本格式读取
              state = read(namedXContentRegistry, stateFile);
              logger.trace("state id [{}] read from [{}]", id, stateFile.getFileName());
          }
          return state;
      } catch (Exception e) {
          exceptions.add(new IOException("failed to read " + pathAndStateId.toString(), e));
          logger.debug(
              (Supplier<?>) () -> new ParameterizedMessage(
                  "{}: failed to read [{}], ignoring...", pathAndStateId.file.toAbsolutePath(), prefix), e);
      }
  }
  // ....
  return state;
}

在方法read内会解析真正的文件内容。

ES聚合查询流程

ES每一次查询通过netty服务传递查询命令，以下是聚合查询流程：

sequenceDiagram;  Netty4HttpRequestHandler->>Netty4HttpRequestHandler: 读取数据  Netty4HttpRequestHandler->>Netty4HttpServerTransport: 传输请求  Netty4HttpServerTransport->>RestController: 分发请求  RestController->>RestController: 遍历所有处理器，查找匹配的handler  alt 查找到匹配的:    RestController->>BaseRestHandler: 处理请求    BaseRestHandler->>RestSearchAction: 解析请求获取具体的处置动作    RestSearchAction->>SearchSourceBuilder: 根据传递过来的json字符串解析请求内容    SearchSourceBuilder->>SearchSourceBuilder: 根据string token，判断不同类型，解析不同的数据    SearchSourceBuilder->>AggregatorFactories: 从字符串中构建出聚合工厂用于后续构建聚合    AggregatorFactories->>AggregatorFactories: 构建聚合工厂    AggregatorFactories->>SearchSourceBuilder: 继续解析其他内容    SearchSourceBuilder->>RestSearchAction: 解析完成    RestSearchAction->>RestSearchAction: 解析查询类型、路由、索引选项以及深度分页请求信息等等    RestSearchAction->>BaseRestHandler: 返回预处理完成的Action    alt: 存在有参数未处理      BaseRestHandler->>BaseRestHandler: 抛出异常    end    BaseRestHandler->>BaseRestHandler: 使用计数+1    BaseRestHandler->>RestSearchAction: 将请求交由RestSearchAction处理    RestSearchAction->>TransportSearchAction: 查询action交由具体Transport执行    TransportSearchAction->>TransportSearchAction: 根据state以及请求获取具体的索引    TransportSearchAction->>TransportSearchAction: 预处理别名    TransportSearchAction->>TransportSearchAction: 查询请求路由    TransportSearchAction->>TransportSearchAction: 获取索引在所有shards上的遍历器    TransportSearchAction->>AbstractSearchAsyncAction: 异步查询解析    AbstractSearchAsyncAction->>InitialSearchPhase: 执行异步查询请求    InitialSearchPhase->>InitialSearchPhase: 分片遍历并在每个分片上执行查询    InitialSearchPhase->>SearchQueryThenFetchAsyncAction: 传递分片信息以及查询请求    SearchQueryThenFetchAsyncAction->>TransportService: 将查询异步请求交由Transport服务来执行    TransportService->>TransportService: 交由localNodeConnection执行查询请求    TransportService->>SearchTransportService: 将请求传递    SearchTransportService->>SearchService: 执行searchService请求查询传入请求以及回调监听    SearchService->>SearchService: 执行查询解析并查询具体结果    SearchService->>QueryPhase: 查询解析    QueryPhase->>AggregationPhase: 聚合预处理，构建顶层聚合    AggregationPhase->>QueryPhase: 预处理完成    QueryPhase->>QueryPhase: 聚合语句执行    QueryPhase->>QueryPhase: 返回执行结果    QueryPhase->>SearchService: 结果返回  end

上述的整个流程过程中，有三处地方对于聚合做了处理：

1. 请求字符串解析出聚合构建器
2. 预处理聚合构建器，构建出top聚合
3. 聚合语句执行

这三处地方，并没有对于聚合字段做特殊判断，比如在聚合的时候会直接选择keyword属性。而是需要在请求的时候，显示指定字段类型为keyword类型的标识。

总结

如果需要在聚合的时候直接使用keyword，则显示指定它。

SpringBoot项目增加Spring拦截器，但是却发现没有生效；debug DispatchServelt，发现在查找handler的时候，由于存在多个RequestMappingHandlerMapping实例，而匹配到的handlerMaping实例内interceptors列表为空，所以无法使得拦截器生效。

追踪问题

为什么存在两个handlerMapping实例？

路由映射关系初始化探究

先看一下handlerMapping是什么时候初始化的。
在DispatcherServelt类里，在刷新应用上下文（onRefresh）的时候，方法initStrategies会执行，如下代码：

1
2
3
4
5
6
7
8
9
10
11

protected void initStrategies(ApplicationContext context) {
    initMultipartResolver(context);
    initLocaleResolver(context);
    initThemeResolver(context);
    initHandlerMappings(context);
    initHandlerAdapters(context);
    initHandlerExceptionResolvers(context);
    initRequestToViewNameTranslator(context);
    initViewResolvers(context);
    initFlashMapManager(context);
}

重点在于initHandlerMappings方法，在这个方法里面初始化了handlerMapping：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

private void initHandlerMappings(ApplicationContext context) {
    this.handlerMappings = null;

    // 是否检测所有的映射
    if (this.detectAllHandlerMappings) {
        // 查找上下文的所有HandlerMapping实例
        Map<String, HandlerMapping> matchingBeans =
                BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerMapping.class, true, false);
        if (!matchingBeans.isEmpty()) {
            this.handlerMappings = new ArrayList<HandlerMapping>(matchingBeans.values());
            // 不为空的情况下进行排序
            AnnotationAwareOrderComparator.sort(this.handlerMappings);
        }
    }
    else {
        // 获取主要的handlerMapping
        try {
            HandlerMapping hm = context.getBean(HANDLER_MAPPING_BEAN_NAME, HandlerMapping.class);
            this.handlerMappings = Collections.singletonList(hm);
        }
        catch (NoSuchBeanDefinitionException ex) {
            // Ignore, we'll add a default HandlerMapping later.
        }
    }

    // 如果没有handlerMapping，则创建一个默认的
    if (this.handlerMappings == null) {
        this.handlerMappings = getDefaultStrategies(context, HandlerMapping.class);
        if (logger.isDebugEnabled()) {
            logger.debug("No HandlerMappings found in servlet '" + getServletName() + "': using default");
        }
    }
}

detectAllHandlerMappings值为true，则会从上文中查询实现了HandlerMapping接口的所有子类。找到AbstractHandlerMethodMapping抽象类，所有的控制层路由跳转（举例@RequestMapping）都通过AbstractHandlerMethodMapping实现。

可以看到在AbstractHandlerMethodMapping类内，实现了InitializingBean接口；同时在afterPropertiesSet方法内，执行了initHandlerMethods方法并初始化了handlerMapping。

罪魁祸首定位

在initHandlerMethods方法内通过debug断点运行应用后，发现在这里执行了两次；很明显，应用实例化了两次AbstractHandlerMethodMapping子类。

看了下AbstractHandlerMethodMapping类的所有子类，列举了下各自子类的大致用途：

真正需要关注的是RequestMappingHandlerMapping子类，看了下真正的调用方只有WebMvcAutoConfiguration配置类内的方法，如下代码：

1
2
3
4
5
6

@Bean
@Primary
@Override
public RequestMappingHandlerMapping requestMappingHandlerMapping() {
    return super.requestMappingHandlerMapping();
}

在这里，创建了一个名为requestMappingHandlerMapping的RequestMappingHandlerMapping实例类，其他地方并未进行相关的创建。在想到请求的时候，存在两个RequestMappingHandlerMapping实例，那么肯定有其他入口能够创建新的实例。

经过N小时的折腾查询（过程不堪回首），终于发现是应用内的ImportResource引入的。

1
2
3
4
5
6
7
8
9

@SpringBootApplication(scanBasePackages = {"com.xxx"})
@ImportResource("classpath*:spring/applicationContext.xml")
public class BootstrapApp {

    public static void main(String[] args) {
        SpringApplication.run(BootstrapApp.class);
    }

}

上述代码，在应用启动类上加了@ImportResource("classpath*:spring/applicationContext.xml")。这个就是罪魁祸首。

原因探究

为什么@ImportResource在注入的过程中会注册一个RequestMappingHandlerMapping实例，且为啥这个实例没有被@Primary覆盖？

定位到ConfigurationClassPostProcessor类，这个类是对所有配置类文件做解析。在方法processConfigBeanDefinitions内使用ConfigurationClassParser类具体执行解析操作。具体可以看这篇文章【Spring-Bean解析分析过程】

在方法doProcessConfigurationClass内

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// 处理任意@ImportResource注解
if (sourceClass.getMetadata().isAnnotated(ImportResource.class.getName())) {
    AnnotationAttributes importResource =
            AnnotationConfigUtils.attributesFor(sourceClass.getMetadata(), ImportResource.class);
    // 获取注解上的资源位置
    String[] resources = importResource.getStringArray("locations");
    // 获取资源的解释器
    Class<? extends BeanDefinitionReader> readerClass = importResource.getClass("reader");
    for (String resource : resources) {
        String resolvedResource = this.environment.resolveRequiredPlaceholders(resource);
        // 将资源位置和对应的解释器放入配置文件实例内
        configClass.addImportedResource(resolvedResource, readerClass);
    }
}

解析了@ImportResource，并把属性注入到配置文件类内，在这里只是一个标记，并没真正处理。

解析完成后，ConfigurationClassBeanDefinitionReader类会读取配置类文件，并加载所有的beanDefinition：

1
2
3
4
5
6
7

// 读取资源内容并且根据内容创建bean定义
if (this.reader == null) {
    this.reader = new ConfigurationClassBeanDefinitionReader(
            registry, this.sourceExtractor, this.resourceLoader, this.environment,
            this.importBeanNameGenerator, parser.getImportRegistry());
}
this.reader.loadBeanDefinitions(configClasses);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

private void loadBeanDefinitionsForConfigurationClass(ConfigurationClass configClass,
TrackedConditionEvaluator trackedConditionEvaluator) {

    if (trackedConditionEvaluator.shouldSkip(configClass)) {
        String beanName = configClass.getBeanName();
        if (StringUtils.hasLength(beanName) && this.registry.containsBeanDefinition(beanName)) {
            this.registry.removeBeanDefinition(beanName);
        }
        this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());
        return;
    }

    if (configClass.isImported()) {
        registerBeanDefinitionForImportedConfigurationClass(configClass);
    }
    for (BeanMethod beanMethod : configClass.getBeanMethods()) {
        loadBeanDefinitionsForBeanMethod(beanMethod);
    }
    loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
    loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}

在这里可以看到对解析的做了处理，重点关注loadBeanDefinitionsFromImportedResources方法，这个方法对引入的资源做了解析并注册为beanDefinition。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

private void loadBeanDefinitionsFromImportedResources(
Map<String, Class<? extends BeanDefinitionReader>> importedResources) {

    Map<Class<?>, BeanDefinitionReader> readerInstanceCache = new HashMap<Class<?>, BeanDefinitionReader>();

    for (Map.Entry<String, Class<? extends BeanDefinitionReader>> entry : importedResources.entrySet()) {
        String resource = entry.getKey();
        Class<? extends BeanDefinitionReader> readerClass = entry.getValue();

        // Default reader selection necessary?
        if (BeanDefinitionReader.class == readerClass) {
            if (StringUtils.endsWithIgnoreCase(resource, ".groovy")) {
                // .groovy脚本文件解析
                readerClass = GroovyBeanDefinitionReader.class;
            }
            else {
                // 主要对于.xml文件的解析，也可以解析其他文件
                readerClass = XmlBeanDefinitionReader.class;
            }
        }

        // 通过readerClass获取具体的reader实例
        BeanDefinitionReader reader = readerInstanceCache.get(readerClass);
        if (reader == null) {
            try {
                // 如果不存在则实例化reader
                reader = readerClass.getConstructor(BeanDefinitionRegistry.class).newInstance(this.registry);
                // Delegate the current ResourceLoader to it if possible
                if (reader instanceof AbstractBeanDefinitionReader) {
                    AbstractBeanDefinitionReader abdr = ((AbstractBeanDefinitionReader) reader);
                    abdr.setResourceLoader(this.resourceLoader);
                    abdr.setEnvironment(this.environment);
                }
                readerInstanceCache.put(readerClass, reader);
            }
            catch (Throwable ex) {
                throw new IllegalStateException(
                        "Could not instantiate BeanDefinitionReader class [" + readerClass.getName() + "]");
            }
        }

        // 通过reader读取bean定义
        reader.loadBeanDefinitions(resource);
    }
}

在这个类里面，reader根据导入资源文件格式实例化后，通过reader来读取bean定义。像我们这里导入的是xml资源文件，则会生成XmlBeanDefinitionReader实例。

在这个实例对于元素的具体解析里，可以看到答案：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

@Override
public BeanDefinition parse(Element element, ParserContext parserContext) {
    Object source = parserContext.extractSource(element);
    XmlReaderContext readerContext = parserContext.getReaderContext();

    CompositeComponentDefinition compDefinition = new CompositeComponentDefinition(element.getTagName(), source);
    parserContext.pushContainingComponent(compDefinition);

    RuntimeBeanReference contentNegotiationManager = getContentNegotiationManager(element, source, parserContext);

    // 创建了一个HanderMapping的bean定义
    RootBeanDefinition handlerMappingDef = new RootBeanDefinition(RequestMappingHandlerMapping.class);
    handlerMappingDef.setSource(source);
    handlerMappingDef.setRole(BeanDefinition.ROLE_INFRASTRUCTURE);
    handlerMappingDef.getPropertyValues().add("order", 0);
    handlerMappingDef.getPropertyValues().add("contentNegotiationManager", contentNegotiationManager);

    if (element.hasAttribute("enable-matrix-variables")) {
        Boolean enableMatrixVariables = Boolean.valueOf(element.getAttribute("enable-matrix-variables"));
        handlerMappingDef.getPropertyValues().add("removeSemicolonContent", !enableMatrixVariables);
    }
    else if (element.hasAttribute("enableMatrixVariables")) {
        Boolean enableMatrixVariables = Boolean.valueOf(element.getAttribute("enableMatrixVariables"));
        handlerMappingDef.getPropertyValues().add("removeSemicolonContent", !enableMatrixVariables);
    }

    // 在这里注册handerMapping的bean定义
    configurePathMatchingProperties(handlerMappingDef, element, parserContext);
    readerContext.getRegistry().registerBeanDefinition(HANDLER_MAPPING_BEAN_NAME , handlerMappingDef);

    // ....其他代码省略

    return null;
}

可以看到，在这段代码内创建了名为org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping的bean定义。

而WebMvcAutoConfiguration创建的handlerMapping的bean定义名为requestMappingHandlerMapping。

这个导致的后果就是，IOC容器内存在两个RequestMapping。

解决问题

有如下三种方法：

1. 定义RequestMapping的顺序，但是两者都是系统载入，无法修改定义。
2. 将xml的配置更改为注解配置，这样就可以避免上述的问题
3. 设置detectAllHandlerMappings值为false

总结

在不了解内部机制的情况下，真的不能滥用一些配置，因为往往会造成一些出人意料的事情。

最近在学习Linux内核体系知识，需要C的一个编译环境。但是由于笔者使用环境为MacOS，并非使用的Linux体系操作系统，在进行内核编程的时候就无法调用linux系统函数；然后在折腾了一遍ubuntu虚拟机、实体机（显卡问题）后，意外发现了CLion的远程调试功能。

构建远程编译环境

CLion的远程运行环境需要如下程序：

• rsync(for macos or linux locally)
• sftp & gzip(for windows locally)
• CMake(2.18.x-3.14.x)
• Make
• C compiler
• C++ Compiler
• GDB(7.x-8.x)

安全完成后，配置如下：

• 配置远程调试：
  

• 配置认证：
  

完成配置后，会自动同步一次源文件到/tmp目录下的某个临时文件夹内。

注意：如果需要重新同步，只需要右键项目，选择Reload CMake Project即可。

远程调试原理

CLion的远程调试基于文件传输以及GDB服务：

1. 上传项目目录至远程服务器【mac或者linux使用rsync，windows使用sftp和gzip同步程序】
2. 远端检索所有头文件，并下载缓存到本地的.remote/${ip}_${port}/文件夹下
3. Debug的时候，同步Debug标记文件和二进制文件【具体单点调试步骤未知，TODO】

附录

• CLion远程原理讲解

在做JSR269的深度解析的时候，需要对javac的源代码进行单步调试并跟踪。因此在这里记录下具体的调试步骤。

调试环境：
OS: MacOS 10.14.5
JDK：JDK_1.8
IDEA: IntelliJ IDEA 2019.1.3

下载Javac源码

可以直接用JDK的github镜像仓库处下载，链接在此处；下载完成后checkout tag至：jdk8-b120。如果本地安装的是Oracle JDK，则源代码可能会有些细微差别。

修改IDEA监听端口

Help -> Edit Custom VM Options

在最后增加如下代码：

1

-Dcompiler.process.debug.port=12346

增加port后，idea在编译的时候，会自动开启监听端口12346。

修改完成后记得需要重启IDEA

创建一个远程调试程序

如上图，Host设置为localhost，Port设置为12346。

启用编译调试

默认IDEA会禁用编译调试，这里需要开启一个开关，以此让IDEA在编译之前等待调试程序的链接。并且，这个配置在IDEA重启后会失效。

双击Shift，打开平常搜索类的界面，输入debug build process，如下图：

点击启用：

测试

点击编译，IDEA状态栏会出现如下提示：

这个就代表javac编译器正在等待调试程序接入。

在main/Main.java类内compile()方法打上断点，并启动远程调试程序，即可进行javac的调试。

That’s all

最近一直在了解DDD相关的知识，自己也以DDD构建了几个应用；网上有许多关于DDD的理论知识，但是对于实例讲解，特别是Java语言的较为稀少。

DDD设计思路

在设计控制台这个应用的时候，整体思路沿用的是DDD驱动设计那本书的思路。

0. 整理用户用例需求
1. 构建统一语言
2. 构建限界上下文
3. 构建上下文映射图
4. 构建领域模型

需求用例

• 用户输入命令，控制台根据命令选择执行者，执行者执行命令后，响应命令输出，并创建快照
• 用户可以在当前会话查看命令快照，并且选择撤销到某个命令快照上，在这个节点前的所有命令全部回滚
• 用户可以将多个命令存储为批处理命令，在本次会话中重复性调用执行
• 用户可以拦截命令执行之前，执行任务之后，执行任务失败，执行任务成功，执行完成的点；即，命令的生命周期

提取实体构建统一语言

根据上述需求，提取名词，这些名词就是需要构建的实体。
上述需求的实体包含有：命令、执行者、批处理、命令结果、历史、命令快照、回滚脚本、会话

构建出如下通用语言：

构建限界上下文

从提取的实体中，我们按照”高聚合、低耦合“的方式划分不同的领域聚合。划分限界上下文如下图：

很显然，聚合根已经清晰：

• 命令
• 历史
• 会话

构建上下文映射

由需求用例，我们可以了解到聚合和聚合之间的联系。

• 命令执行后创建
• 在会话中查看历史
• 命令执行后创建快照

构建出如下上下文映射图：

构建领域模型

上述实体、聚合根已经明确，互相之间的关系可以通过用例需求来描述清楚，构建出如下领域模型：

方案落地

整体思路已经明确，可以根据上述的领域模型构建出大体的领域层，主要分为三个包，类似三个限界上下文：

• command
• session
• history

Command核心子域

Command是核心子域，是整个控制台的能力体现，主要解决用户命令执行的逻辑。

在这个限界上下文内定义了Command类，并实现了执行、回撤的能力。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

/**
 * Command aggregate root
 *
 * behavior:
 * 1. execute
 * 2. undo
 *
 * @author WhatAKitty
 * @date 2019/05/01
 * @description
 **/
@Data
@EqualsAndHashCode(callSuper = true)
public abstract class Command extends AbstractAggregateRoot<String> implements ICommand {

    /**
     * command name
     */
    private final String name;
    /**
     * the receiver to actually execute
     */
    private final IReceiver receiver;

    public Command(AggregateId<String> id, String name, IReceiver receiver) {
        super(id);
        this.name = name;
        this.receiver = receiver;
    }

    @Override
    public CommandResult execute(Session session) {
        publishEvent(new CommandBeforeExecuteEvent(session));
        try {
            // invoke
            final Object result = execute(session, receiver);
            publishEvent(new CommandAfterExecuteEvent(session, result));
            return CommandResult.of(true, result);
        } catch (Throwable e) {
            publishEvent(new CommandExecuteFailedEvent(session, e));
            return CommandResult.of(false, null);
        } finally {
            publishEvent(new CommandFinishedEvent(session));
        }
    }

    @Override
    public void undo(Session session) {
        if (!supportUndo()) {
            throw new UnsupportedOperationException("unsupported undo operation");
        }
        // undo
        undo(session, receiver);
    }

    /**
     * create a batch command task
     *
     * @param commands commands list
     * @return batch command instance
     */
    public static BatchCommand createBatch(List<ICommand> commands) {
        return new BatchCommand(commands);
    }

    protected abstract Object execute(Session session, IReceiver receiver);

    protected Object undo(Session session, IReceiver receiver) {
        return null;
    }

}

在这里，Command类被声明为抽象类，因为命令这个聚合根比较特殊，每个聚合根值都是以类的形式存在的，每个具体命令都有自身的执行逻辑。

Command类内每个具体的Command都有一个对应的Receiver，也就是执行者；在执行者内会执行这个命令的具体逻辑，然后将CommandResult，也就是执行结果返回给用户。

比如，在这里默认实现的显示历史命令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

/**
 * show history command
 *
 * @author WhatAKitty
 * @date 2019/05/02
 * @description
 **/
public class ShowHistoryCommand extends Command {

    public static final String COMMAND_TIP = "history";

    public ShowHistoryCommand(AggregateId<String> id) {
        super(id, COMMAND_TIP, new ShowHistoryReceiver());
    }

    @Override
    protected Object execute(Session session, IReceiver receiver) {
        receiver.invoke(session);
        return null;
    }

    @Override
    public boolean supportUndo() {
        return false;
    }

    /**
     * show history receiver
     */
    public static final class ShowHistoryReceiver extends Receiver {

        public ShowHistoryReceiver() {
            super(session -> session.getHistory().showHistory());
        }

    }

}

历史命令继承了Command抽象类，它是一个具体的聚合根值。在命令执行逻辑这里，它将会话参数传递到了执行者处，进行具体的执行。
在这段逻辑内：

1

super(session -> session.getHistory().showHistory());

会话本身会获取会话内存储的命令历史，并执行它的能力，显示历史命令快照列表。

Session支撑子域

Session作为承上启下的支撑子域，内部能力非常丰富，包含有添加用户自定义参数、获取参数、绑定命令快照历史、设置当前执行命令等等能力。

在这里主要描述它的绑定历史以及设置当前命令的两个能力。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
  * bind history into this session
  *
  * @param fetcher not exists history, do get it from fetcher
  */
public History bindHistory(HistoryFetcher fetcher) {
    if (this.history != null) {
        return this.history;
    }

    synchronized (HISTORY_LOCK) {
        if (this.history == null) {
            this.history = fetcher.invoke();
        }
        return this.history;
    }
}

如上代码是绑定历史的具体实现，如果在发现当前会话无历史的情况下，会在加锁的条件下，从fetcher中获取命令历史的实例进行绑定。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

/**
  * current command to execute
  */
@Getter
private final ThreadLocal<ICommand> command = new ThreadLocal<>();

public void setCurrentCommand(ICommand cmd) {
    command.set(cmd);
}

public ICommand currentCommand() {
    return command.get();
}

public void removeCommand() {
    command.remove();
}

设置当前命令、获取当前命令、移除当前命令主要通过ThreadLocal类来实现，按照控制台设计，用户在执行某个命令的时候是单线程操作。

历史子域

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

/**
 * history aggregate root
 *
 * @author WhatAKitty
 * @date 2019/05/02
 * @description
 **/
public class History extends AbstractAggregateRoot<String> {

    /**
     * the stack of command snapshot
     */
    private final Stack<CommandSnapshot> stack = new Stack<>();
    /**
     * session
     */
    private final Session session;

    public History(AggregateId<String> id, Session session) {
        super(id);
        this.session = session;
    }

    /**
     * add command into history stack
     *
     * @param command the command to execute successfully
     */
    public void addHistory(ICommand command) {
        // ignore history command itself
        if (command instanceof ShowHistoryCommand) {
            return;
        }
        // create command snapshot and push the snapshot into history stack
        stack.push(CommandSnapshot.snapshot(command));
    }

    /**
     * show the commands execute previously
     */
    public void showHistory() {
        int total = stack.size();
        for (int i = 0; i < total; i++) {
            CommandSnapshot snapshot = stack.get(i);
            StreamMgr.getINSTANCE().println(String.format("[%s] %s", i + 1, snapshot.getName()));
        }
    }

    /**
     * rollback the current stage
     *
     * @param index the rollback index, started with 1
     */
    public void rollback(int index) {
        // check arguments
        if (index < 1 || stack.size() < index) {
            throw new IllegalArgumentException("exceed max rollback");
        }

        for (int i = 1; i <= index; i++) {
            CommandSnapshot snapshot = stack.remove(i - 1);
            snapshot.undo(session);
            StreamMgr.getINSTANCE().println(String.format("The command %s has been undo", snapshot.getName()));
        }
    }

}

历史子域是对命令快照的一个管理，在执行完命令后，可以创建一个命令快照存入历史栈内；在展现命令快照列表的时候，可以从站内读取命令快照。在回滚的时候，可以以栈的形式出栈并执行回滚命令，如果命令不支持回滚，则会回滚失败。

Application层以及仓储层

应用控制台主要为了能够让用户调用命令，那么势必需要将各领域的能力做一个结合：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

/**
 * command service
 *
 * execute command and add execute history
 *
 * @author WhatAKitty
 * @date 2019/05/02
 * @description
 **/
@RequiredArgsConstructor
@Service
public class CommandService {

    private final CommandRepository commandRepository;
    private final HistoryRepository historyRepository;
    private final HistoryFactory historyFactory;

    /**
     * 执行命令
     *
     * @param session session
     * @param cmd     command
     */
    public Optional<CommandResult> execute(Session session, String cmd) {
        // 获取或者重新创建绑定一个命令历史
        session.bindHistory(() -> {
          // 创建命令历史
            History newOne = historyFactory.create(session);
            historyRepository.create(newOne);
            return newOne;
        });

        // 执行具体命令
        try {
            // 根据cmd从仓储中获取某个具体命令来执行  ①
            return commandRepository.findById(AggregateId.of(cmd))
                .map(command -> {
                    session.setCurrentCommand(command);
                    return command.execute(session);
                });
        } finally {
            session.removeCommand();
        }
    }

    /**
     * 创建批处理
     *
     * @param session   session
     * @param batchName batch command name
     * @param cmds      user defined command list
     * @return create successfully
     */
    public boolean createBatch(Session session, String batchName, List<String> cmds) {
        // 从仓储中获取所有命令 ②
        List<ICommand> commands = commandRepository.findInIds(cmds.parallelStream()
            .map(AggregateId::of)
            .collect(Collectors.toList()));
        BatchCommand batchCommand = Command.createBatch(commands);
        // 将批处理作为一个新命令存储到仓储 ③
        return commandRepository.saveCommand(batchName, batchCommand);
    }

}

在①、②、③处，都需要跟仓储交互，在仓储中，存储了cmd以及command的实例；在每次应用启动后，都会讲命令以及命令实例的映射加载到内存中以供使用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

/**
 * default command repository
 *
 * @author WhatAKitty
 * @date 2019/05/03
 * @description
 **/
public class DefaultCommandRepository extends InMemoryRepository<String, ICommand> implements CommandRepository {

    @Override
    public Optional<ICommand> findById(AggregateId<String> commandId) {
        return Optional.ofNullable(get(commandId));
    }

    @Override
    public List<ICommand> findInIds(List<AggregateId<String>> commandIds) {
        return commandIds.parallelStream()
            .map(this::get)
            .filter(Objects::nonNull)
            .collect(Collectors.toList());
    }

    @Override
    public boolean saveCommand(String commmandName, ICommand command) {
        return putIfAbsent(AggregateId.of(commmandName), command) == null;
    }

    @Override
    protected void init() {
        // 每次启动后，都会加载如下两个命令。 ④
        AggregateId<String> showHistoryId = AggregateId.of(ShowHistoryCommand.COMMAND_TIP);
        AggregateId<String> undoHistoryId = AggregateId.of(UnDoCommand.COMMAND_TIP);
        put(showHistoryId, new ShowHistoryCommand(showHistoryId));
        put(undoHistoryId, new UnDoCommand(undoHistoryId));
    }
}

在④处加载了默认的两个命令，一个是展示历史、一个是回滚命令。

如果需要扩展，则可以继承并覆写该方法：

1
2
3
4
5
6
7
8
9
10
11

@Component
public class DemoCommandRepository extends DefaultCommandRepository {

    @Override
    protected void init() {
        super.init();
        final AggregateId<String> id = AggregateId.of(SayHelloWorldCommand.COMMAND_TIP);
        put(id, new SayHelloWorldCommand(id));
    }

}

总结

That’s all.

附录

基础控制台代码
控制台样例代码

今日在线上linux查看日志追踪一个问题的时候，钉钉突然接收到告警信息，提示服务crash。

追查过程

由于在JVM启动的时候，并未加入-XX:ErrorFile参数，也就是说没有JVM crash的日志可以查看。服务器采用的是Centos的操作系统，就想到可以利用linux进程监控日志查看crash信息。

输入命令cat /var/log/messages获得如下错误进程生命周期：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: AliYunDun invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0   ①
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: AliYunDun cpuset=/ mems_allowed=0
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: CPU: 1 PID: 11084 Comm: AliYunDun Not tainted 3.x.x-x.x.x.x.x86_64 #1
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS rel-1.7.5-0-xxxxxx-20xxxxxx_164612-nilsson.home.kraxel.org xx/xx/xxxx
...
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: Call Trace:
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff816a3db1>] dump_stack+0x19/0x1b
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff8169f1a6>] dump_header+0x90/0x229
May 13 13:46:19 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff810e939c>] ? ktime_get_ts64+0x4c/0xf0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff8113d36f>] ? delayacct_end+0x8f/0xb0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff81186394>] oom_kill_process+0x254/0x3d0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff81185e3d>] ? oom_unkillable_task+0xcd/0x120
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff81185ee6>] ? find_lock_task_mm+0x56/0xc0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff81186bd6>] out_of_memory+0x4b6/0x4f0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff8169fcaa>] __alloc_pages_slowpath+0x5d6/0x724
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff8118cd85>] __alloc_pages_nodemask+0x405/0x420
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff811d1108>] alloc_pages_current+0x98/0x110
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff81182917>] __page_cache_alloc+0x97/0xb0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff81184eb0>] filemap_fault+0x170/0x410
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffffc01be156>] ext4_filemap_fault+0x36/0x50 [ext4]
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff811ad162>] __do_fault+0x52/0xe0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff811ad60b>] do_read_fault.isra.44+0x4b/0x130
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff811b1f11>] handle_mm_fault+0x691/0xfa0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff816a8fad>] ? __schedule+0x39d/0x8b0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff816afff4>] __do_page_fault+0x154/0x450
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff816b03d6>] trace_do_page_fault+0x56/0x150
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff816afa6a>] do_async_page_fault+0x1a/0xd0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [<ffffffff816ac578>] async_page_fault+0x28/0x30
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Mem-Info:
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: active_anon:908086 inactive_anon:113 isolated_anon:0#012 active_file:1161 inactive_file:3251 isolated_file:27#012 unevictable:0 dirty:6 writeback:0 unstable:0#012 slab_reclaimable:14131 slab_unreclaimable:4393#012 mapped:372 shmem:188 pagetables:3329 bounce:0#012 free:22809 free_pcp:71 free_cma:0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 DMA free:15360kB min:276kB low:344kB high:412kB active_anon:384kB inactive_anon:0kB active_file:4kB inactive_file:4kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:24kB slab_unreclaimable:32kB kernel_stack:0kB pagetables:8kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:696 all_unreclaimable? yes
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: lowmem_reserve[]: 0 2814 3773 3773
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 DMA32 free:53992kB min:50208kB low:62760kB high:75312kB active_anon:2728428kB inactive_anon:400kB active_file:4144kB inactive_file:15476kB unevictable:0kB isolated(anon):0kB isolated(file):108kB present:3129216kB managed:2884232kB mlocked:0kB dirty:24kB writeback:0kB mapped:1456kB shmem:648kB slab_reclaimable:40652kB slab_unreclaimable:9472kB kernel_stack:7824kB pagetables:10588kB unstable:0kB bounce:0kB free_pcp:360kB local_pcp:120kB free_cma:0kB writeback_tmp:0kB pages_scanned:19438 all_unreclaimable? yes
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: lowmem_reserve[]: 0 0 958 958
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 Normal free:17048kB min:17096kB low:21368kB high:25644kB active_anon:904132kB inactive_anon:52kB active_file:496kB inactive_file:624kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1048576kB managed:981548kB mlocked:0kB dirty:0kB writeback:0kB mapped:28kB shmem:104kB slab_reclaimable:15848kB slab_unreclaimable:8068kB kernel_stack:2352kB pagetables:2720kB unstable:0kB bounce:0kB free_pcp:144kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:3131 all_unreclaimable? yes
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: lowmem_reserve[]: 0 0 0 0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 DMA: xxxx...
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 DMA32: xxxx...
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 Normal: xxxx...
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: 5490 total pagecache pages
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: 0 pages in swap cache
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Swap cache stats: add 0, delete 0, find 0/0
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Free swap  = 0kB
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Total swap = 0kB
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: 1048446 pages RAM
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: 0 pages HighMem/MovableOnly
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: 78024 pages reserved
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  335]     0   335    21498       88      42        0             0 systemd-journal
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  357]     0   357    49101       93      28        0             0 lvmetad
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  366]     0   366    11047      223      21        0         -1000 systemd-udevd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  448]     0   448     5402       70      16        0             0 irqbalance
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  450]    81   450     6104      100      18        0          -900 dbus-daemon
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  452]   997   452   133564     2422      56        0             0 polkitd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  454]     0   454     6110      137      18        0             0 systemd-logind
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  461]     0   461    31559      163      19        0             0 crond
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  462]     0   462     6464       52      18        0             0 atd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  487]     0   487    27511       32      10        0             0 agetty
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  488]     0   488    27511       33      11        0             0 agetty
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  502]    38   502    11282      188      28        0             0 ntpd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  699]     0   699    26499      255      53        0         -1000 sshd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [  700]     0   700   140609     3183      91        0             0 tuned
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [ 3171]     0  3171    29478      157      12        0             0 wrapper
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [ 3173]     0  3173   639160    17634      93        0             0 java
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [18771]     0 18771    12428      375      22        0             0 ilogtail_0.16.1
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [18772]     0 18772    35548     1153      49        0             0 ilogtail_0.16.1
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [11045]     0 11045     8187      424      21        0             0 AliYunDunUpdate
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [11063]     0 11063    34061     2169      63        0             0 AliYunDun
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [28916]     0 28916   158555      797     165        0             0 rsyslogd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [20779]   996 20779    24617      279      48        0             0 xxx_agentd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [20780]   996 20780    24642      362      48        0             0 xxx_agentd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [20781]   996 20781    24642      311      48        0             0 xxx_agentd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [20782]   996 20782    24642      323      48        0             0 xxx_agentd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [20783]   996 20783    24642      305      48        0             0 xxx_agentd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [20784]   996 20784    24617      287      48        0             0 xxx_agentd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [14212]     0 14212    37927      840      24        0             0 xxxxxx-collect
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [ 6680]     0  6680    74406     5748      60        0             0 filexxxx
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [28753]     0 28753    10448      216      13        0             0 aliyun-service
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [28775]  1000 28775  1303596   610152    1401        0             0 java
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [29015]     0 29015    36554      335      73        0             0 sshd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [29020]  1000 29020    36554      325      71        0             0 sshd
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [29021]  1000 29021    28848      113      13        0             0 bash
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: [29143]  1000 29143   288690   251514     517        0             0 vim
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Out of memory: Kill process 28775 (java) score 630 or sacrifice child      ②
May 13 13:46:20 xxxxxxxxxxxxxxxxxxxxxxx kernel: Killed process 28775 (java) total-vm:5214384kB, anon-rss:2440608kB, file-rss:0kB, shmem-rss:0kB

在①处可以看到AliyunDun的一个日志，在这里触发了一个OOM Killer。然后干掉了OOM Score最高的Java 进程。

而在②处可以看到OOM Killer真实的杀死了进程ID为28775的java进程。

想了下，13::46左右，刚好打开了一个2G的日志文件，很可能是这个原因，造成AliyunDun申请内存不足，因此触发OOM Killer杀死进程。

什么是OOM Killer

OOM Killer 顾名思义即为在out of memory的情况下杀死占内存最多又不重要的进程的程序。

为什么会存在OOM Killer

这个问题源于Linux的内存申请机制，它执行的是一个积极的内存申请策略。

即：执行maclloc()返回非null的地址并不能保证内存是真实可用的（在maclloc()申请内存的机制中描述这是个非常坑的BUG），因为linux允许程序申请比系统可用空间更多的空间，该特性被称为overcommit特性，这样做是为了系统优化。并且并不是所有程序申请了内存就会立刻使用，当真正使用的时候，系统可能已经回收一部分内存。而一旦真正使用的时候发现没有内存，系统将会为了防止系统耗尽内存而触发OOM Killer，这个时候将会萱蕚性的杀死一个甚至多个进程，用于给新程序腾出空间。

linux可以选择overcommit的策略，甚至直接禁用overcommit。

但是只要启用overcommit策略，那么必定会有OOM Killer。OOM Killer可以根据一些用户定义的策略来决定哪些进程需要被kill掉。它的底层通过/proc/<pid>/oom_score值来判断哪个进程需要被干掉。如下描述一些相关策略以及对应文件：

• /proc/<pid>/oom_score_adj：用于在计算得到最终badness score的时候累加。-1000代表永远不会被kill；+1000代表最大可能被kill
• /proc/<pid>/oom_adj：为了与旧版本操作系统兼容，写入或者读取的时候会按照比例写入读取到oom_score_adj文件；可能存在一定的精度丢失的情况发生
• /proc/<pid>/oom_score：最终的分数，用于判断哪个进程需要被kill

OOM kill的内核实现

• 引用自内存管理

OOM的调用关系：

1
2

__alloc_pages_nodemask -> __alloc_pages_slowpath -> __alloc_pages_may_oom -> out_of_memory ->
__out_of_memory -> select_bad_process -> oom_kill_process

其逻辑操作如下：

1. 首先通过函数 blocking_notifier_call_chain 遍历用户注册的通知链函数，如果通知链的callback函数能够处理OOM，则直接退出OOM killer操作。
2. 如果引起OOM的进程（current）拥有pending SIGKILL，或者正在退出，则选择current进程。
3. 检查发生OOM时，内核是否需要panic，如果panic，这后续代码就不会执行。
4. 如果设置了 sysctl_oom_kill_allocating_task ，并且 current->mm 不为空，current的 oom_score_adj != OOM_SCORE_ADJ_MIN ，且可以杀死current，则直接杀死current进程，释放内存。
5. 调用 select_bad_process 选择一个最优的进程p去杀
6. 如果 p == null， 即没有进程可杀，内核则直接panic，否则调用函数 oom_kill_process 去kill选择选择的进程p。

select_bad_process操作：

1. 该函数遍历所有的进程和线程 for_each_process_thread(g, p)
2. 针对每一个线程：该函数先利用 oom_scan_process_thread 检查线程的类别，排除一些特殊的线程，然后对可以作为候选的线程进行评分。
3. 最后返回评分最高的线程。

注意：第2步骤中，排除的线程包括：

• init进程
• kernel thread线程
• 进程没有可以释放的内存
• 不是引起oom的memcg中的进程
• 进程正被OOM kill
• …

如何防止进程被Kill

• /proc/<pid>/oom_score_adj设置值为-1000
• /proc/<pid>/oom_adj设置值为-17
• 完全关闭OOM Killer，# sysctl -w vm.overcommit_memory=2 # echo "vm.overcommit_memory=2" >> /etc/sysctl.conf，不推荐用于生产环境。可能造成内存混乱。

总结

• 对于服务进程，需要针对性做一些措施，防止由于某些原因造成的内存OOM情况。
• 在日志打印上，还需要控制单日志文件的大小，超过的做分割

参考资料

• 内存管理 — 内核知识 v0.1 documentation
• linux - How does the OOM killer decide which process to kill first? - Unix & Linux Stack Exchange

一直在使用Lombok以及MapStruct，但是对于它们能够在编译阶段直接生成实例代码却没有仔细了解过。最近刚好在部门内做了一次分享，也在这里对具体原理做一个详细阐述。

Lombok以及MapStruct实现大体思路

Lombok以及MapStruct都是通过在目标代码上标记注解，编译器能够根据注解生成对应的实现代码。比如Lombok在属性上标记@Getter，那么在这个Java Bean内就会生成对应属性的get方法。

本质上来说，不管是Lombok或者MapStruct，都是通过Java的一个标准API来实现的；这个API即为Pluggable Annotation Processing API，简称为JSR269。

JSR269

借用JSR269官方原文定义（附带原文地址：https://jcp.org/en/jsr/detail?id=269）：

J2SE 1.5 added a new Java language mechanism “annotations” that allows annotation types to be used to annotate classes, fields, and methods. These annotations are typically processed either by build-time tools or by run-time libraries to achieve new semantic effects. In order to support annotation processing at build-time, this JSR will define APIs to allow annotation processors to be created using a standard pluggable API. This will simplify the task of creating annotation processors and will also allow automation of the discovery of appropriate annotation processors for a given source file.
The specification will include at least two sections, a section of API modeling the Java programming language and a distinct section for declaring annotation processors and controlling how they are run. Since annotations are placed on program elements, an annotation processing framework needs to reflect program structure. Annotation processors will be able to specify what annotations they process and multiple processors will be able to run cooperatively.
The processors and program structure api can be accessed at build-time; i.e. this functionality supplements core reflection support for reading annotations.

译文如下：

J2SE 1.5 增加了一种新的Java语言机制”annotations“，它允许注解被用于类、字段以及方法上。这些注解由 build-time 工具以及 run-time 库处理，来达到新的语义效果。为了支持在 build-time 时处理注解，这个JSR定义了通用的插入式API用于创建标准的注解处理器。这将简化创建注解处理器的任务，并且还能够根据源文件自动匹配响应的注解处理器。
该规范将至少包含两个部分，一部分用于建模Java编程语言的API，另一部分用于声明注解处理器以及他们的运作机制。由于注解被用于程序元素上，一个注解处理框架需要反映程序结构。注解处理器将能指定哪些注解是它们可以处理的，以及多个注解处理器如何协同工作。
注解处理器以及程序框架api可以在 build-time 时访问；举个例子，此功能提供了核心反射支持用于读取注解（注：一般指从源码内读取注解或者只读取标注为source-only的注解）。

即，在J2SE 1.6版本加入的JSR269的主要点如下：

• 专门用于支持 J2SE 1.5 无法处理的 build-time 注解处理场景，并定义通用注解处理API
• 引入程序框架api

JSR269运行机制

sequenceDiagram;  javac/Main->>javac/Main: new main.Main("javac)  javac/Main->>main/Main: 编译参数传递  main/Main->>main/Main: Javac上下文创建  main/Main->>main/Main: JavaFileManager.preRegister预注册  main/Main->>main/Main: 执行compile并传递编译参数以及上下文  main/Main-->>javac/Main: 参数有误显示帮助信息  main/Main->>main/Main: 参数解析(获取class以及files并初始化注解处理器路径)  alt 解析的文件为空且含有注解处理参数    main/Main-->>javac/Main: 无source.files.classes  else 存在文件或者无注解处理参数    main/Main->>main/Main: JavaCompiler实例创建    main/Main->>main/JavaCompiler: 传递源文件列表以及类列表    alt PROC为none值      main/JavaCompiler->>main/JavaCompiler: 不初始化    else PROC非none值      main/JavaCompiler->>main/JavaCompiler: 初始化注解      main/JavaCompiler->>processing/JavaProcessingEnvironment: 设置Processors      processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 从参数获取processors      processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: processors初始化并赋值给discoveredProcs    end    main/JavaCompiler->>main/JavaCompiler: 处理注解    main/JavaCompiler->>main/JavaCompiler: 将需要的package注解以及class注解加入待处理列表    main/JavaCompiler->>processing/JavaProcessingEnvironment: 传递上下文、待处理的包类注解列表    processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 构造Round    loop 循环直到没有新文件产生(moreToDo方法)      processing/JavaProcessingEnvironment->>processing/Round: 构造JavacRoundEnvironment，传递包类      processing/Round->>processing/Round: 通过顶层的包类找到所有支持的注解      loop 循环discoveredProcs        processing/Round->>processing/Round: 通过变量annotationsPresent判断这个注解是否支持        alt 注解支持          processing/Round->>processing/Round: 加入待处理列表；matchedNames添加支持的注解名        else 注解不支持          processing/Round->>processing/Round: 不做处理，继续下一步        end        alt matchedNames是否不为空且处理器是否已被执行          processing/Round->>processing/Round: 调用注解处理器的process方法          processing/Round->>processing/Round: 标记注解处理器已被执行          alt 执行结果是为true            processing/Round->>processing/Round: unmatchedAnnotations移除matchedNames内所有匹配的项          else 执行结果为false            processing/Round->>processing/Round: 不做处理，继续下一步          end        else           processing/Round->>processing/Round: 不做处理，继续下一步        end      end      processing/Round-->>processing/JavaProcessingEnvironment: 一次round循环完成      processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 构建下一个round    end    processing/JavaProcessingEnvironment->>processing/Round: 执行最后一次run方法    processing/Round->>processing/DiscoveredProcessors: 所有执行过的processor会带上空注解集合参数再次执行一遍    processing/DiscoveredProcessors-->>processing/Round: 完成执行    processing/Round-->>processing/JavaProcessingEnvironment: 完成最后一次round    processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 判断本次是否存在错误，存在则标记errorStatus    processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 清理所有包类    processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 构建为最终编译使用的JavaCompiler    alt errorStatus状态为true      processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 错误数不为0返回编译器      processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: 错误数为0日志记录无错误+1    else erroStatus状态为false      processing/JavaProcessingEnvironment->>processing/JavaProcessingEnvironment: enterTrees    end    processing/JavaProcessingEnvironment-->>main/JavaCompiler: 返回编译器    main/JavaCompiler-->>main/Main: 执行编译完成    alt 错误数大于0      main/Main-->>javac/Main: 执行错误    else 为空      main/Main-->>javac/Main: 执行正确    end  end

样例

构建三个模块：

1. 注解处理类以及目标注解类
2. 注解注册为服务
3. 调用方

注解类以及处理类

注解类：

1
2
3
4
5
6
7

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.SOURCE)
public @interface Test {

    String value();

}

注解处理类：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@SupportedAnnotationTypes(value = {"com.whatakitty.learn.jsr269.Test"})
@SupportedSourceVersion(value = SourceVersion.RELEASE_8)
public class AnnotationProcessor extends AbstractProcessor {

    private Messager messager;
    private AtomicInteger atomicInteger;

    @Override
    public void init(ProcessingEnvironment env) {
        messager = env.getMessager();
        atomicInteger = new AtomicInteger(0);
        super.init(env);
    }

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        messager.printMessage(Diagnostic.Kind.NOTE, "Hello World!" + atomicInteger.incrementAndGet());
        return true;
    }
}

注册服务

在文件夹resources/META-INF/services下创建文件javax.annotation.processing.Processor，内容如下：

1

com.whatakitty.learn.jsr269.AnnotationProcessor

调用方

1
2
3
4
5
6
7
8
9
10
11
12

public class Test1 {

    public static void main(String[] args) throws Exception {
        System.out.println("success");
        test();
    }

    @Test("method is test")
    public static void test() throws Exception {
    }

}

运行结果

可以看到，上图中已经输出两次Hello World!。至于为什么会输出两次，是由于第一次是本身注解的处理调用；最后一次是，jdk会在所有注解处理完成后，将所有处理过的注解全部传入空注解再次执行一遍，代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

/**
  * Run all remaining processors on the procStateList that
  * have not already run this round with an empty set of
  * annotations.
  */
public void runContributingProcs(RoundEnvironment re) {
  if (!onProcInterator) {
    // 构造空的注解元素集合
    Set<TypeElement> emptyTypeElements = Collections.emptySet();
    // 遍历所有注册的注解处理器
    while(innerIter.hasNext()) {
        ProcessorState ps = innerIter.next();
        // 判断该注解处理器是否在之前处理过注解，未参与过的不会调用
        if (ps.contributed)
          // 传入空的注解元素集合，重新调用一次注解处理器
          callProcessor(ps.processor, emptyTypeElements, re);
    }
  }
}

Lombok原理

Lombok基于JSR269 API实现了通过特定注解生成对应代码的功能。

Lombok主要在类LombokProcessor处理了自己的注解通过AST生成代码。如下，主要看两个重写方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107

// 初始化本次处理的一些变量等
@Override public void init(ProcessingEnvironment procEnv) {
  super.init(procEnv);
  // 判断lombok是否被禁用
  if (System.getProperty("lombok.disable") != null) {
    lombokDisabled = true;
    return;
  }

  this.processingEnv = procEnv;
  this.javacProcessingEnv = getJavacProcessingEnvironment(procEnv);
  this.javacFiler = getJavacFiler(procEnv.getFiler());

  // 替换类加载器、对netbeans IDE相关hook处理、替换JavaFileManager
  placePostCompileAndDontMakeForceRoundDummiesHook();
  trees = Trees.instance(javacProcessingEnv);
  transformer = new JavacTransformer(procEnv.getMessager(), trees);
  // 获取标记HandlerPriority注解的所有优先级
  SortedSet<Long> p = transformer.getPriorities();
  if (p.isEmpty()) {
    this.priorityLevels = new long[] {0L};
    this.priorityLevelsRequiringResolutionReset = new HashSet<Long>();
  } else {
    this.priorityLevels = new long[p.size()];
    int i = 0;
    // 循环所有获取到的注释或者visit处理优先级
    for (Long prio : p) this.priorityLevels[i++] = prio;
    this.priorityLevelsRequiringResolutionReset = transformer.getPrioritiesRequiringResolutionReset();
  }
}

/** {@inheritDoc} */
@Override public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
  // 如果禁用，则不处理lombok注解
  if (lombokDisabled) return false;
  // 是否已经处理结束
  if (roundEnv.processingOver()) {
    cleanup.run();
    return false;
  }
  
  // We have: A sorted set of all priority levels: 'priorityLevels'
  
  // Step 1: Take all CUs which aren't already in the map. Give them the first priority level.
  
  String randomModuleName = null;
  
  // 标记所有编译单元的优先级
  // 如果是第二次循环，因为roots已经包含了这个编译单元，所以会忽略
  for (Element element : roundEnv.getRootElements()) {
    if (randomModuleName == null) randomModuleName = getModuleNameFor(element);
    JCCompilationUnit unit = toUnit(element);
    if (unit == null) continue;
    if (roots.containsKey(unit)) continue;
    roots.put(unit, priorityLevels[0]);
  }
  
  while (true) {
    // Step 2: For all CUs (in the map, not the roundEnv!), run them across all handlers at their current prio level.
    
    // 循环优先级列表
    for (long prio : priorityLevels) {
      List<JCCompilationUnit> cusForThisRound = new ArrayList<JCCompilationUnit>();
      // 获取在该优先级下的所有编译单元并加入该优先级下需要处理的编译单元列表内
      for (Map.Entry<JCCompilationUnit, Long> entry : roots.entrySet()) {
        Long prioOfCu = entry.getValue();
        if (prioOfCu == null || prioOfCu != prio) continue;
        cusForThisRound.add(entry.getKey());
      }
      // 按照优先级顺序执行编译单元
      // 访问AST树并编译目标注解
      transformer.transform(prio, javacProcessingEnv.getContext(), cusForThisRound, cleanup);
    }
    
    // Step 3: Push up all CUs to the next level. Set level to null if there is no next level.
    
    // 排除掉列表第一个优先级准备执行下一次循环
    Set<Long> newLevels = new HashSet<Long>();
    for (int i = priorityLevels.length - 1; i >= 0; i--) {
      Long curLevel = priorityLevels[i];
      Long nextLevel = (i == priorityLevels.length - 1) ? null : priorityLevels[i + 1];
      List<JCCompilationUnit> cusToAdvance = new ArrayList<JCCompilationUnit>();
      for (Map.Entry<JCCompilationUnit, Long> entry : roots.entrySet()) {
        if (curLevel.equals(entry.getValue())) {
          cusToAdvance.add(entry.getKey());
          newLevels.add(nextLevel);
        }
      }
      for (JCCompilationUnit unit : cusToAdvance) {
        roots.put(unit, nextLevel);
      }
    }
    newLevels.remove(null);
    
    // Step 4: If ALL values are null, quit. Else, either do another loop right now or force a resolution reset by forcing a new round in the annotation processor.
    
    // 判断是否将所有优先级排除，优先级列表为空，则结束
    if (newLevels.isEmpty()) return false;
    newLevels.retainAll(priorityLevelsRequiringResolutionReset);
    if (!newLevels.isEmpty()) {
      // Force a new round to reset resolution. The next round will cause this method (process) to be called again.
      forceNewRound(randomModuleName, javacFiler);
      return false;
    }
    // None of the new levels need resolution, so just keep going.
  }
}

init方法主要是做一些初始化；

process方法内主要是将注解以及visitor处理器的按照优先级划分，然后每次执行完成后，排除最开始的一个优先级后，重新开始下一轮编译。知道所有优先级排除完毕。这么做的原因，应该是为了在高优先级处理器处理完成生成文件后，能够让低优先级处理器根据高优先级处理器生成的文件重新执行一遍防止遗漏生成的新的代码

总结

• 详细了解了JSR269内部的执行逻辑
• 了解了JAVAC的编译过程
• 了解了Lombok内部的执行原理，可以依托现有Lombok处理器，自定义注解

总之，收获满满。

笔者在最近应用国际化校验的时候，碰到一个奇怪的问题：国际化始终不能生效，消息返回的仍旧是模板消息。

相关源码

Java Bean:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

@Data
public class DemoParam {

    @NotNull(message = "{validator.demo.name.not-null}")
    private String name;

    @NotNull(
        groups = DemoParamValidateGroup1.class,
        message = "{validator.demo.title.not-blank}"
    )
    @NotEmpty(
        groups = DemoParamValidateGroup1.class,
        message = "{validator.demo.title.not-blank}"
    )
    @Length(
        min = 1,
        max = 64,
        groups = DemoParamValidateGroup1.class,
        message = "{validator.demo.title.illegal-length-1-64}"
    )
    private String title;

    /**
     * first validation group
     */
    public interface DemoParamValidateGroup1 {}

}

DemoApi:

1
2
3
4

@PostMapping("/param1")
public Object param1(@Validated @RequestBody DemoParam demoParam) {
    return Result.getSuccResult(demoParam);
}

ValidatorConfig:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Configuration
public class ValidatorConfig {

    private final MessageSource messageSource;

    public ValidatorConfig(MessageSource messageSource) {
        this.messageSource = messageSource;
    }

    @Bean
    public Validator validator() {
        LocalValidatorFactoryBean validator = new LocalValidatorFactoryBean();
        validator.setValidationMessageSource(messageSource);
        return validator;
    }

}

DemoApiTest:

1
2
3
4
5
6
7
8
9
10
11

@Test
public void test_param1_default() throws Exception {
    DemoParam demoParam = new DemoParam();

    mockMvc.perform(
        post("/api/demo/param1")
            .contentType(MediaType.APPLICATION_JSON_UTF8)
            .content(JSON.toJSONString(demoParam)))
        .andExpect(status().isOk())
        .andExpect(jsonPath("$.code", is(DemoResultCode.BAD_REQUEST.getCode())));
}

定位问题

由于笔者并没有在以前看过spring的validator源码；所以，打算从校验的执行入口处入手。

请求是POST形式，而在类RequestResponseBodyMethodProcessor的resolveArgument方法内，会对注解有@RequestBody的参数做参数解析。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

@Override
public Object resolveArgument(MethodParameter parameter, @Nullable ModelAndViewContainer mavContainer,
    NativeWebRequest webRequest, @Nullable WebDataBinderFactory binderFactory) throws Exception {

  parameter = parameter.nestedIfOptional();
  Object arg = readWithMessageConverters(webRequest, parameter, parameter.getNestedGenericParameterType());①
  String name = Conventions.getVariableNameForParameter(parameter);

  if (binderFactory != null) {
    WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name);
    if (arg != null) {
      validateIfApplicable(binder, parameter);
      if (binder.getBindingResult().hasErrors() && isBindExceptionRequired(binder, parameter)) { ②
        throw new MethodArgumentNotValidException(parameter, binder.getBindingResult());
      }
    }
    if (mavContainer != null) {
      mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult());
    }
  }

  return adaptArgumentIfNecessary(arg, parameter);
}

在上述的解析块内，① 处的代码是使用MessageHttpConverters将json字符串转化为目标实例；② 处的代码通过创建的WebDataBinder获取校验后的结果，通过结果判断是否校验通过。而我们需要的错误信息构建肯定在validateIfApplicable(binder, parameter);语句内。

1
2
3
4
5
6
7
8
9
10
11
12

protected void validateIfApplicable(WebDataBinder binder, MethodParameter parameter) {
  Annotation[] annotations = parameter.getParameterAnnotations();
  for (Annotation ann : annotations) {
    Validated validatedAnn = AnnotationUtils.getAnnotation(ann, Validated.class);
    if (validatedAnn != null || ann.annotationType().getSimpleName().startsWith("Valid")) { ③
      Object hints = (validatedAnn != null ? validatedAnn.value() : AnnotationUtils.getValue(ann));
      Object[] validationHints = (hints instanceof Object[] ? (Object[]) hints : new Object[] {hints});
      binder.validate(validationHints); ④
      break;
    }
  }
}

③ 处在校验参数的时候，会校验参数的注解是否有注解，如果注解为@Validated或者注解以Valid开头，则校验该参数，如 ④ 处的代码；binder是类DataBinder的实例，校验的逻辑如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public void validate(Object... validationHints) {
  Object target = getTarget();
  Assert.state(target != null, "No target to validate");
  BindingResult bindingResult = getBindingResult(); ⑤
  // Call each validator with the same binding result
  for (Validator validator : getValidators()) {
    if (!ObjectUtils.isEmpty(validationHints) && validator instanceof SmartValidator) {
      ((SmartValidator) validator).validate(target, bindingResult, validationHints); ⑥
    }
    else if (validator != null) {
      validator.validate(target, bindingResult); ⑥
    }
  }
}

⑤ 处代码创建一个默认的校验结果，然后传递进入实际的校验方法 ⑥ 内。在Spring Boot框架内，校验框架的实现交由Hibernate Validator实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public final <T> Set<ConstraintViolation<T>> validate(T object, Class<?>... groups) {
  Contracts.assertNotNull( object, MESSAGES.validatedObjectMustNotBeNull() );
  sanityCheckGroups( groups );

  ValidationContext<T> validationContext = getValidationContextBuilder().forValidate( object );

  if ( !validationContext.getRootBeanMetaData().hasConstraints() ) {
    return Collections.emptySet();
  }

  ValidationOrder validationOrder = determineGroupValidationOrder( groups );
  ValueContext<?, Object> valueContext = ValueContext.getLocalExecutionContext(
      validatorScopedContext.getParameterNameProvider(),
      object,
      validationContext.getRootBeanMetaData(),
      PathImpl.createRootPath()
  );

  return validateInContext( validationContext, valueContext, validationOrder ); ⑦
}

在 ⑦ 处，通过校验和值的上下文校验具体的内容；之后在ConstraintTree类内做具体的校验，其中的层次调用就不在本篇内描述。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

protected final <T, V> Set<ConstraintViolation<T>> validateSingleConstraint(ValidationContext<T> executionContext,
ValueContext<?, ?> valueContext,
ConstraintValidatorContextImpl constraintValidatorContext,
ConstraintValidator<A, V> validator) {
  boolean isValid;
  try {
    @SuppressWarnings("unchecked")
    V validatedValue = (V) valueContext.getCurrentValidatedValue();
    isValid = validator.isValid( validatedValue, constraintValidatorContext );
  }
  catch (RuntimeException e) {
    if ( e instanceof ConstraintDeclarationException ) {
      throw e;
    }
    throw LOG.getExceptionDuringIsValidCallException( e );
  }
  if ( !isValid ) {
    //We do not add these violations yet, since we don't know how they are
    //going to influence the final boolean evaluation
    return executionContext.createConstraintViolations( ⑧
        valueContext, constraintValidatorContext
    );
  }
  return Collections.emptySet();
}

在 ⑧ 处，可以看到在这里创建错误信息的实例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

public ConstraintViolation<T> createConstraintViolation(ValueContext<?, ?> localContext, ConstraintViolationCreationContext constraintViolationCreationContext, ConstraintDescriptor<?> descriptor) {
  String messageTemplate = constraintViolationCreationContext.getMessage(); ⑨
  String interpolatedMessage = interpolate( ⑩
      messageTemplate,
      localContext.getCurrentValidatedValue(),
      descriptor,
      constraintViolationCreationContext.getMessageParameters(),
      constraintViolationCreationContext.getExpressionVariables()
  );
  // at this point we make a copy of the path to avoid side effects
  Path path = PathImpl.createCopy( constraintViolationCreationContext.getPath() );
  Object dynamicPayload = constraintViolationCreationContext.getDynamicPayload();

  switch ( validationOperation ) {
    case PARAMETER_VALIDATION:
      return ConstraintViolationImpl.forParameterValidation(
          messageTemplate,
          constraintViolationCreationContext.getMessageParameters(),
          constraintViolationCreationContext.getExpressionVariables(),
          interpolatedMessage,
          getRootBeanClass(),
          getRootBean(),
          localContext.getCurrentBean(),
          localContext.getCurrentValidatedValue(),
          path,
          descriptor,
          localContext.getElementType(),
          executableParameters,
          dynamicPayload
      );
    case RETURN_VALUE_VALIDATION:
      return ConstraintViolationImpl.forReturnValueValidation(
          messageTemplate,
          constraintViolationCreationContext.getMessageParameters(),
          constraintViolationCreationContext.getExpressionVariables(),
          interpolatedMessage,
          getRootBeanClass(),
          getRootBean(),
          localContext.getCurrentBean(),
          localContext.getCurrentValidatedValue(),
          path,
          descriptor,
          localContext.getElementType(),
          executableReturnValue,
          dynamicPayload
      );
    default:
      return ConstraintViolationImpl.forBeanValidation(
          messageTemplate,
          constraintViolationCreationContext.getMessageParameters(),
          constraintViolationCreationContext.getExpressionVariables(),
          interpolatedMessage,
          getRootBeanClass(),
          getRootBean(),
          localContext.getCurrentBean(),
          localContext.getCurrentValidatedValue(),
          path,
          descriptor,
          localContext.getElementType(),
          dynamicPayload
      );
  }
}