基于 CAS 机制的 ConcurrentHashMap 实现内幕

曾经写过一篇《基于锁分段机制的 ConcurrentHashMap 实现内幕》的文章,介绍了在 jdk 1.7 之前 ConcurrentHashMap 的实现机制。文章的结尾我们提及到在 jdk 1.8 之后,ConcurrentHashMap 在实现上抛弃了锁分段机制,转而采用 CAS(Compare And Swap) 策略,并和 HashMap 一样引入了红黑树的支持。本文我们将基于 jdk 1.8 源码,分析基于 CAS 机制的 ConcurrentHashMap 实现。

阅读全文

JMockit:单元测试利器

单元测试(UT: Unit Test)是保证服务质量的基础。在实际项目的 UT 开发中,我们通常需要执行第三方服务调用、连接数据库等操作,为了让 UT 能够正常运行起来,我们需要执行大量的环境准备工作,这些工作有时比 UT 本身还要费时费力很多,而 mock 机制则能够帮助我们绕开这些必要但不一定要真正需要去做的事情,隔离 UT 与服务的依赖,模拟我们期望的行为和数据。

阅读全文

Spring AOP 源码解析:注解式切面增强机制

IoC 和 AOP 被称为 Spring 两大基础模块,支撑着上层扩展的实现和运行。虽然 AOP 同样建立在 IoC 的实现基础之上,但是作为对 OOP(Object-Oriented Programing) 的补充,AOP(Aspect-Oriented Programming) 在程序设计领域拥有其不可替代的适用场景和地位,而 Spring AOP 作为 AOP 思想的实现,被誉为 spring 框架的基础模块也算是实至名归。Spring 在 1.0 版本的时候就引入了对 AOP 的支持,并且随着版本的迭代逐渐提供了基于 XML 配置、注解,以及 schema 配置的使用方式,考虑到实际开发中使用注解配置的方式相对较多,所以本文主要分析注解式 AOP 的实现和运行机制。

阅读全文

CGLib:The Missing Guide

CGLib(Code Generation Library) 是一个强大、高效,以及高质量的字节码生成库,能够在运行时动态生成字节码,从而实现一些比较极客的功能。CGLib 被许多开源软件采用,我们在写一些基础库时也很青睐,但是官方给到的文档比较简单,所以本文参考 CGLib: The missing manual,并结合自己的使用经验,总结了一个中文版本。

阅读全文

JStorm 源码解析:ACK 机制

Ack 机制是 storm 能够保证消息至少被处理一次(at least once)的核心,从而保证消息不丢失。在 topology 有向无环图中,spout 向 bolt 发射消息,上游 bolt 也会向下游 bolt 发射消息,storm 设置了一类 acker 类型的系统 bolt 用于接收所有组件发送的 ack 消息,监控数据在 topology 中的处理情况。如果处理成功则发送 __acker_ack 消息给 spout,否则发送 __acker_fail 消息给 spout,然后 spout 依据相应的消息类型采取一定的应对措施(例如消息重发等)。

阅读全文

JStorm 源码解析:worker 的启动和运行机制

上一篇我们分析了 supervisor 节点的启动和运行过程,提及到 supervisor 的核心工作就是基于 ZK 从 nimbus 节点领取分配给它的任务,并启动 worker 执行。一个 worker 就是一个 JVM 进程,运行在 supervisor 节点上,多个 task 可以同时运行在一个 worker 进程之中,每个 task 都对应一个线程。 Worker 进程的启动位于 Worker 类中,前面我们在分析 supervisor 节点的启动过程时提及到了对于 Worker 类 main 函数的触发,supervisor 在启动相应 worker 进程时会指定 topologyId、supervisorId、workerPort、workerId,以及 classpath 等参数,worker 在拿到这些参数之后会先获取当前机器上端口对应的老进程,并逐一 kill 掉,然后调用 Worker#mk_worker 方法创建并启动对应的 worker 实例,

阅读全文

JStorm 源码解析:supervisor 的启动和运行机制

Supervisor 节点可以理解为单机任务调度器,它负责监听 nimbus 节点的任务资源分配,启动相应的 worker 进程执行 nimbus 分配给当前节点的任务,同时监测 worker 的运行状态,一旦发现有 worker 运行异常,就会杀死该 worker 进程,并将原先分配给 worker 的任务交还给 nimbus 节点进行重新分配。 Supervisor 节点的启动过程位于 Supervisor 类中,main 方法的实现比较简单,主要就是创建了一个 Supervisor 类对象,并调用实例方法 Supervisor#run,

阅读全文

JStorm 源码解析:nimbus 的启动和运行机制

本篇我们一起分析一下 nimbus 节点的启动和运行机制。Nimbus 节点是 storm 集群的调度者和管理者,它是集群与用户交互的窗口,负责 topology 任务的分配、启动和运行,也管理着集群中所有的 supervisor 节点的运行,监控着整个集群的运行状态,并将集群运行信息汇集给 UI 进行展示。 Nimbus 节点的启动过程位于 NimbusServer 类中,这是一个驱动类,main 方法中会加载集群配置文件,包括 default.yaml 和 storm.yaml,并将配置文件内容与启动时的命令行参数一起封装成 map 对象便于后续使用,真正的启动逻辑位于 NimbusServer#launchServer 方法中:

阅读全文

JStorm 源码解析:基础线程模型

在具体开始分析 storm 集群的启动和运行机制之前,我们先来看一下基础的线程模型,在整个 storm 的实现中有很多地方用到它,所以将其单独拎出来先分析说明一下,后面看到相应的类就大致知道其内在的运行过程啦。 在 storm 的实现中,有很多实现了 RunnableCallback 类的子类,这些类实例化之后都被传递给了 AsyncLoopThread 对象,

阅读全文

JStorm 源码解析:拓扑任务的资源分配过程

上一篇我们分析了 topology 构建和提交过程在客户端的逻辑,并最终通过 submitTopology 方法向 storm 集群的 nimbus 节点提交任务。Nimbus 以 Thrift RPC 服务的方式运行,相应 thrift 接口方法实现位于 ServiceHandler 类中,下面我们从 ServiceHandler#submitTopology 方法切入,分析 nimbus 节点之于客户端提交任务的资源分配过程,该方法包装了 ServiceHandler#submitTopologyWithOpts 方法。 Storm 集群的任务提交主要分为三种类型:新任务提交、热部署,以及灰度发布。ServiceHandler#submitTopologyWithOpts 方法统一处理这三种情况,但是不管哪种提交方式都会首先验证 topology 名称和配置的合法性,然后基于具体提交类型分而治之。

阅读全文

Powered by hexo & Theme by hiero   Copyright © 2015-2019 浙ICP备 16010916  号,指 · 间 All Rights Reserved.