Hadoop源码剖析：从HDFS到YARN的核心链路与调试实战

每天处理海量数据的人，真正翻开过Hadoop源码的可能连一成都不到。我讲一次真实经历：凌晨两点，某个DataNode坏了一块盘，NameNode卡在安全模式，我围着日志转了快两个小时，最后能做的只是重启节点；第二天面试官问“FSImage和EditLog到底怎么配合恢复元数据”，我发现自己背过的所谓八股文根本接不住这种提问。所以后来我花了整整一个多月，把Hadoop主链路的源码过了一遍，拿到的回报不仅仅是面试答案，更重要的是线上出问题时能直接定位到具体类、具体RPC调用，而不是靠猜。

这篇内容会围绕Hadoop源码拆解展开：先讲清楚源码阅读的路线规划，怎么选版本、怎么编译、工程里有哪些模块；然后挑HDFS、YARN、MapReduce三个核心模块，把主链路源码一条条捋出来；再讲怎么把源码跑起来断点调试；最后分享一些踩坑记录和面试高频源码问题。适合三类人：一是准备大数据岗位面试、不想只背概念的人；二是集群出问题后对黑盒排查感到吃力、想掌握排障硬技能的人；三是打算在Hadoop生态上做二次开发的人。小白也可以读，我会尽量把每一步原理和实操拆开讲。

1. 源码剖析的整体思路：先规划路线，再动手

1.1 明确你的目标：面试、排障还是二次开发

若是一开始就抱着“把Hadoop所有代码全啃完”的心态，用不了一周就会放弃。这套源码光是Java代码就超过百万行，还牵扯到Protocol Buffers、NativeIO、Jetty、Netty等外部依赖，没有目标地通读只会迷失在类名大海里。我建议先回答一个问题：你翻开源码到底要解决什么？

我把常见目标分成三类。

第一类是面试。面试考察的源码问题通常集中在固定几个点上：NameNode启动时FSImage和EditLog如何处理、HDFS写文件三副本怎么选节点、YARN的调度器如何分配资源、MapTask环形缓冲区到底怎么绕。这些适合用“链路型阅读”来准备，一条链路对应一个场景，读完立即能在纸上画出来，面试时只要把链路讲清楚，基本就能答出八十分。

第二类是线上排障。这类目标最适合“问题驱动型阅读”：今天你遇到DataNode频繁掉线，就去追DataNode心跳线程和RPC处理链路；明天你遇到小文件过多导致NameNode内存暴涨，就去看INode和Block的存储结构。看得少而精，但每次都能落地，长期积累下来，排障工具箱会越来越完备。

第三类是二次开发。比如你想自定义一个调度器，或者对NameNode的元数据做扩展，那就必须把现有实现类的接口、生命周期、上下文关系彻底读透，这种读法最慢，也最考验功力。

选好目标后，后续所有阅读方式和深度都会不一样。没有这个前提，下面的方法直接用容易失控。

1.2 版本选择与源码获取：别一上来就找master

源码版本选择，直接影响你编译和调试的体验。很多人喜欢去GitHub直接拉最新master，结果编译完发现IDEA里import的类路径跟参考文档对不上，调试时怎么都复现不了教程里的现象。Hadoop的master分支变化很快，连模块结构都可能调整，你辛辛苦苦搭好的调试环境可能一周后就过时了。

我建议选稳定的release tag。Hadoop 2.x的话可以选2.10.2，Hadoop 3.x可以选3.3.4或3.3.6。3.x里hadoop-hdfs模块拆成了hadoop-hdfs和hadoop-hdfs-client，读客户端代码时要注意这个拆分，如果你的目标是跟踪客户端写数据链路，3.x的拆分反而让服务端和客户端代码更清晰，推荐直接用3.x。

源码获取方式有两种：一种是直接下载发行版源码包，可以用清华镜像，下载速度比GitHub release稳定得多；另一种是git clone官方仓库，然后checkout到指定tag。我个人更推荐前者，源码包剥离了仓库历史，目录干净，IDEA加载时不会因为.git目录拖慢索引。需要注意，源码包解压出的目录名里通常带版本号，后续编译时不要在路径里带中文或空格，否则容易遇到各种奇怪问题。

1.3 源码工程结构：先看懂模块地图

拿到源码后别急着展开，先看根目录下的pom.xml和各个子模块。Hadoop采用Maven多模块工程，里面最核心的几个模块我用表格列一下：

刚上手时，我建议不要碰native模块，它的编译依赖Linux环境和系统库，容易劝退。先集中在Java侧，把hadoop-common里的Configuration加载逻辑和RPC机制搞明白，后面看很多链路都会顺畅很多。

一个很容易被忽略的点：RPC是整个Hadoop的血管。NameNode和Client之间、DataNode与NameNode之间、YARN各组件之间，大量通信走的是Hadoop RPC，它基于Protobuf序列化，通过动态代理和NIO实现。你如果把这个机制读明白了，再去看DataNode心跳、块报告、客户端读写，会突然觉得清晰很多。

1.4 编译环境搭建：把整个工程跑起来

再说环境。我的编译环境是CentOS 7.x + JDK 8（Hadoop 3.3.x也可以配JDK 8，如果编译更高版本需要JDK 11），Maven 3.6+，Protobuf 2.5.0，以及必要的C++工具链、cmake等。这些是为native代码准备的，如果你只编译Java模块，并且不打算运行需要native的ShortCircuit（短路读），可以适当精简，不过为了后续调试时行为一致，我建议还是把protobuf装对版本。

这里特别强调protobuf的版本。Hadoop 3.x对protobuf编译器版本要求比较严格，用2.5.0版本通常能一路编译过；用其他版本可能在生成代码时抛异常。我见过不少人在这一步卡住，问题就出在protobuf版本和Hadoop源码里预生成的.proto对象不匹配。

执行编译命令时，建议这样写：

mvn clean package -DskipTests -Pdist -Dmaven.javadoc.skip=true -Dtar

-Pdist会生成完整的发行包，-DskipTests跳过测试，-Dtar生成tar.gz。首次编译要多等一会儿，依赖下载时间很长，建议在settings.xml里配好阿里云镜像或清华镜像，能省下大量时间。

编译成功后，在hadoop-dist/target目录下会生成hadoop-x.x.x目录，这就是可运行的发行包。我的经验是先编译完再导入IDEA，因为编译过程会生成很多需要保留的target目录和类文件，直接导入后IDEA的依赖解析会更稳定，不容易出现找不到符号的报错。

2. HDFS核心链路源码：从一段客户端代码挖到磁盘

2.1 写文件链路：FileSystem.create 背后发生了什么

HDFS的写链路是我认为最适合入门源码啃的一条链路，因为它是纯客户端到服务端的完整RPC过程，几乎覆盖了HDFS一半的核心机制。

先从调用端看。你写一行fs.create(path)，实际进入的是DistributedFileSystem.create()，它内部会调用DFSClient.primitiveCreate()，创建DFSOutputStream。这一步并没有真正在NameNode上建文件，只是做了客户端侧的流对象初始化。真正的创建发生在流写入第一个块时，DataStreamer线程会向NameNode发送addBlock的RPC请求。

我用一个简化代码片段来展示DataStreamer核心循环：

// org.apache.hadoop.hdfs.DFSOutputStream$DataStreamer @Override public void run() { try { ... // 第一次循环：请求分配新块 locatedBlock = getNewBlock(); // addBlock RPC // 拿到块位置后，向DataNode建立pipeline createBlockOutputStream(nodes, ...); // 进入发送循环，把packet逐个写出去 while (!isClosed && dfsClient.clientRunning) { one = queue.take(); // packet队列 ... writeToDatanode(one); } } catch (Exception e) { ... } }

关键在于：NameNode收到addBlock后，由BlockManager.allocateBlock分配块ID，并由BlockPlacementPolicyDefault根据机架感知原则选择副本节点。默认策略是：第一个副本放在与客户端同机架的节点（如果客户端不在集群内，则随机选一个），第二个副本放在与第一个副本同机架但不同节点的机器上，第三个副本放在不同机架的节点上。这块逻辑就在chooseTarget方法里，我当年排障时遇到过三副本全落在同一机架的情况，后来查代码才发现是机架拓扑配置没写好，NetworkTopology没有识别出不同机架。

管道建立后，客户端会把数据切成packet，默认一个packet大约64KB，packet内部又按dfs.bytes-per-checksum（默认512字节）切分成多个chunk，每个chunk附带CRC32校验值。DataNode侧由DataXceiver.writeBlock接收，再通过BlockReceiver写入本地磁盘。这里有一个经常被忽略的细节：DataNode接收完数据后会发送ack应答，由客户端DataStreamer中的ResponseProcessor线程处理。如果某个DataNode写失败了，客户端会自动走transfer流程，把管道中的坏节点剔除并补写副本，这套容错逻辑都在DataStreamer内部，属于链路中比较复杂的部分。

2.2 读文件链路：块定位、机架感知与短路读

读路径比写路径简单，但它牵扯到“就近读取”和“短路读”两个特性，源码里也很有意思。

客户端执行fs.open(path)时，DFSClient.open()会创建DFSInputStream，构造函数里会发起getBlockLocations的RPC，一次拿到文件的所有块位置信息（LocatedBlocks）。这里有个性能点：如果文件很大，getBlockLocations默认只取前若干块，后续块按需通过seek和getBlockAt再获取。读数据时，DFSInputStream会从LocatedBlocks里找到当前块对应的DataNode列表，然后根据客户端的dfs.client.use.datanode.hostname配置决定是否使用主机名连接，再通过chooseDataNode里的延迟统计选择较近的节点。

机架感知在读路径上也发挥作用。客户端会从返回的LocatedBlock里拿到每个DataNode的NetworkLocation（类似/default-rack/192.168.1.1），距离最近的节点优先。如果客户端自己也在集群内，那么与客户端同机架的DataNode会被优先选中。

再讲短路读。过去HDFS读取本地DataNode上的数据也要通过网络栈走一遍，后来引入了ShortCircuit Read机制：客户端进程如果能直接从本地磁盘读取块文件，就省去网络拷贝。这个功能在源码里对应ShortCircuitRegistry和DomainSocket相关类，配置项是dfs.client.read.shortcircuit和dfs.domain.socket.path。我实际测下来，纯本地短路径读的性能提升非常明显，但前提是客户端和DataNode在同一节点，且需要正确配置Native库，否则会直接回退到普通网络读取。

2.3 NameNode启动与元数据恢复：FSImage和EditLog的协作

面试里最常问的HDFS源码问题，几乎都绕不开NameNode启动时FSImage和EditLog怎么配合。从源码角度看，这个过程的主入口是NameNode.main，之后进入NameNode.initialize，再调用loadNamesystem()。

启动序列大致是：

1. 创建并加载FSImage对象，检查本地namenode目录下的fsimage_*和edits_*文件。
2. FSImage.recoverTransitionRead会读取最新的fsimage文件，把整个元数据镜像加载到内存中，然后从edits日志文件里回放增量操作。
3. 如果存在多个edits文件，会依次合并回放，直到把最新的操作全部应用。
4. 回放完成后，NameNode会定期把内存中的元数据写回新的fsimage，这就是checkpoint过程。

代码里最核心的是FSImage和FSEditLog两个类。FSEditLog维护了一个日志段的列表，每次写操作都要追加一条编辑记录；FSImage.saveFSImage负责把完整元数据保存成镜像文件。这里我建议去读一读FSEditLog.loadJournalSets这个方法，你会看到它如何从多个JournalManager里恢复日志，这对理解HA场景很有帮助。

HA场景下，NameNode与ZooKeeper的集成就体现在DFSZKFailoverController中。两个NameNode通过ZooKeeper的临时节点竞争Active状态，Standby节点持续从JournalNode读取EditLog并回放，保证自己的内存元数据跟上Active进度。很多人在配置HA时只改了ha.zookeeper.quorum和dfs.nameservices，但没有意识到源码层面是ZKFailoverController在维护状态转换。如果启动后两个NameNode一直抢Active，直接去这个类里找grantActive和becomeStandby的调用时机，比翻配置文档更有效。

3. YARN资源调度源码：从一次任务提看到资源分配

3.1 ResourceManager的启动与核心服务

YARN的ResourceManager（简称RM）是所有任务的“大脑”。源码入口在org.apache.hadoop.yarn.server.resourcemanager.ResourceManager，它的main方法会启动一个ResourceManager实例，并在统一生命周期内启动一堆核心服务。

我在第一次看RM源码时最容易晕的是它同时启动了太多服务。整理后你会发现核心就这几个：

• ClientRMService：接收客户端提交应用、查询应用状态的RPC。
• ApplicationMasterService：接收各个ApplicationMaster（AM）的心跳和请求，AM申请资源、释放资源都走这里。
• ResourceTrackerService：接收NodeManager（NM）的注册和心跳，维护节点状态。
• ResourceScheduler：资源调度器，默认是CapacityScheduler，决定资源怎么分给各个应用。
• RMAppManager：管理应用生命周期，负责创建RMApp对象。
• RMContext：一个上下文对象，把RM内部的所有状态和服务串起来，所有组件都能通过它访问共享数据。

这些服务在RMActiveServices.serviceInit和serviceStart里按顺序初始化。如果你要研究RM的启动过程，直接看ResourceManager.main到createAndStartActiveServices这条调用链就够了。不少面试题问“YARN启动时先做初始化还是先启动RPC服务”，其实就是问这个顺序，源码里是先初始化状态存储，再启动RPC服务，最后启动调度器。

3.2 提交一次应用：RMAppImpl 状态机与调度器分配

客户端提交应用时，会调用ClientRMService.submitApplication，RM收到请求后会创建一个RMAppImpl实例，这个类的状态机和心跳机制是整个YARN客户端交互的核心。

RMAppImpl维护了一个非常典型的状态机，所有状态转换都封装成了事件。一条最简单的提交路径是：

NEW -> NEW_SAVING -> SUBMITTED -> ACCEPTED -> RUNNING -> FINISHED

每个状态转换背后都对应了事件处理器，比如RMAppManager收到事件后存储应用信息并提交给调度器。调度器一旦决定接受这个应用，会把APPLICATION_ACCEPTED事件转发给ApplicationMasterService，随后由RMAppAttemptImpl启动第一个Container来运行AM。这里有个面试常考点：AM的启动命令是怎么决定的。答案在ApplicationMasterService和ContainerManagerImpl里，RM在allocate响应中会包含一个ContainerLaunchContext，里面放着AM的启动命令、环境变量、本地资源，这些最终会传递给NM去执行。

CapacityScheduler的分配逻辑在CapacityScheduler.assignContainers方法里。它按照队列层级遍历，先选队列，再选应用，然后为选中的应用分配节点上的资源。每个节点上有一个Resource数据结构，表示CPU和内存容量，默认分配单位由yarn.scheduler.minimum-allocation-mb和yarn.scheduler.minimum-allocation-vcores控制。如果集群出现资源碎片问题，我通常会直接去这个方法里断点查看ResourceCalculator计算出的可用资源，比看各种监控指标快得多。

3.3 NodeManager侧：Container 是怎么起起来的

NodeManager（NM）是真正执行任务的地方。它的核心类包括NodeStatusUpdater、ContainerManagerImpl和ContainerExecutor。

NodeStatusUpdater负责与RM保持心跳，上报节点资源使用情况，并从RM同步新的Container启动命令。ContainerManagerImpl.startContainer是启动Container的入口，它接收来自AM的startContainer命令，经过资源校验、安全问题检查后，调用ContainerExecutor真正启动进程。

ContainerExecutor有多个实现：DefaultContainerExecutor用普通用户启进程，LinuxContainerExecutor配合CGroup做资源隔离。如果要在生产环境排查Container启动失败问题，重点看LinuxContainerExecutor.launchContainer的日志，它经常会因为权限问题、CGroup路径不存在而失败。我遇到过一种情况：NM启动Container时一直报exit code: 127，后来定位到是容器内环境变量缺少JAVA_HOME，根源在ContainerLaunch.sanitizeEnv清理环境变量时把默认的Java路径给过滤掉了，这种问题只有跟源码才能快速定位。

另外，AM与NM之间的通信是短连接。AM通过ContainerManagementProtocol接口向NM发送startContainer、stopContainer请求，这个接口的实现在ContainerManagerImpl。搞清楚这个接口的调用关系，你就明白“AM向NM申请启动Container”和“AM向RM申请资源”是两条完全不同的RPC链路。很多人面试时把这俩混在一起，实际上前者是AM直接跟NM交互，后者是AM把资源请求发给RM，由RM通过心跳响应发放Container。

4. MapReduce源码：别跳过Shuffle，它是灵魂

4.1 Mapper 与环形缓冲区：数据怎么往出写

MapReduce在Hadoop 2.x之后就变成了纯客户端框架，真正执行Map和Reduce任务的其实是YARN上的普通Java进程，入口在org.apache.hadoop.mapred.MapTask。

MapTask.run方法会先判断是否是新API（org.apache.hadoop.mapreduce）还是旧API（org.apache.hadoop.mapred），然后创建对应的Mapper执行器。Mapper的输出并不是直接写磁盘，而是写到一个环形缓冲区MapOutputBuffer里。

这个环形缓冲区的设计非常值得读。默认大小是mapreduce.task.io.sort.mb（默认100MB），当缓冲区使用率达到mapreduce.map.sort.spill.percent（默认0.8）时，后台Spill线程会开始将数据写入磁盘临时文件。写入前会先按分区号（Partitioner）和键排序，这一步也是Map端排序的原理所在。

我建议去看MapOutputBuffer.collect方法，它处理了缓冲区溢出的所有细节，比如绕过Spill线程直接刷盘、缓冲区重写、键值对齐等。很多MapTask卡在99%不结束的问题，实际上就是缓冲区反复Spill导致IO压力过大，这时你去调mapreduce.task.io.sort.mb就比盲目加内存有效得多。

4.2 Shuffle 三个阶段源码：拉取、合并、归并

Shuffle是MapReduce最容易被问、也最容易被误解的环节。从源码角度拆开，其实就是三个阶段：Map端输出准备、Reduce端拉取、Reduce端归并。

Map端输出准备阶段，MapOutputBuffer在Spill结束后会把多个临时文件合并成一个最终输出文件，同时生成一个索引文件记录每个分区在文件中的偏移量。Reduce端拉取阶段，ReduceTask会启动多个Fetcher线程，从各个Map任务的输出地址（MapOutputLocation）拉取属于自己的那部分数据。这里有个细节：Reduce端在拉取前要先向RM获取所有已完成Map任务的位置信息，这部分逻辑在ShuffleSchedulerImpl里。如果某个Map任务还没完成，Reduce端只能等待。

拉取到的数据会先放入MergeManagerImpl管理的内存缓冲，当内存不够时再落盘。最后归并阶段，ReduceTask.runOld会创建MergeThread把内存和磁盘中的排序段合并成一个大集合，交给Reducer逐键处理。整个过程可以用一张表来理解：

读到这里你会发现，Reduce端的排序完全依赖于Map端输出的有序数据，所以mapreduce.job.reduce.slowstart.completedmaps这个参数才变得重要——它控制Reduce启动的早晚，设得太早会导致Reduce端空等Map输出，设得太晚则拖慢整个作业。

4.3 结合源码回放一次完整的MR作业

我用一个最简单的WordCount来把整条源码调用链串起来。

作业提交后，Job.submit会通过YARNRunner把作业提交给RM。RM创建RMAppImpl，调度器分配一个Container用于启动MRAppMaster。MRAppMaster启动后，会通过AMRMClientAsync向RM注册自己，然后开始申请Map和Reduce任务所需的Container。

Map任务启动后会执行MapTask.run，运行Mapper.map处理每一行输入。输出进入MapOutputBuffer，Spill排序后写入磁盘。Reduce任务等所有Map任务完成后，通过Shuffle拉取数据，归并排序后交给Reducer.reduce。最终结果通过OutputCommitter写入HDFS的_temporary目录，任务成功后移到最终输出目录。

这一整套流程里，最值得自己跟一遍源码的是MRAppMaster的Attempt状态流转，因为它把YARN的Container生命周期和MapReduce的Task生命周期绑在一起。你会在那里看到：TaskAttempt状态从NEW到RUNNING再到SUCCEEDED，而这期间MRAppMaster不断与RM进行allocate心跳，用得到的Container启停任务。理解了这条链路，以后再看到“Container运行但Task失败”的日志，第一反应就会是去查TaskAttempt状态，而不是盲目重启作业。

5. 调试环境搭建：把源码跑起来，才能断点跟进去

5.1 用IDEA导入Hadoop源码的正确姿势

读源码最忌讳只看不动。光靠眼睛通读，很多执行流根本记不住，必须把断点打进去跑一遍。这里我分享我调试Hadoop源码的环境搭建方法，整体在国内网络条件下也能顺利跑通。

编译完成后，直接打开IDEA，选择Open，定位到源码根目录的pom.xml，IDEA会把它识别成Maven项目并自动导入。但注意：全量导入会同时加载所有模块，IDEA的索引时间非常长，机器内存小于16G的话建议只导入你想看的模块，比如hadoop-hdfs-project和hadoop-common-project两个模块，这样索引快很多。

导入后需要设置JDK。我保留JDK 8作为Project SDK，这能避免很多源码里使用旧语法导致的编译问题。另外，IDEA里建议打开Annotation Processing，否则某些由Protobuf生成的类在IDE里会显示找不到符号。

还有一个很容易踩的坑：源码里包含很多自动生成的代码，在IDEA里会显示红色错误，这是正常的。不要指望整个源码工程零报错，只要你能跳转到目标类、能打断点就足够了。

5.2 伪分布式模式下的源码调试

伪分布式是调试HDFS和MapReduce最方便的环境。你需要准备四份配置：

• core-site.xml：配置fs.defaultFS为hdfs://localhost:9000。
• hdfs-site.xml：配置dfs.replication为1，并指定namenode和datanode数据目录。
• mapred-site.xml：配置mapreduce.framework.name为yarn（如果只想跑本地模式，可以设成local）。
• yarn-site.xml：配置YARN相关参数。

配好之后，启动顺序是：先hdfs namenode -format格式化元数据，再启动NameNode和DataNode进程，最后启动YARN的RM和NM。这套步骤对应热词里常出现的“hadoop伪分布式搭建”和“hadoop开发环境搭建”，很多教程把配置写在最后，但我是建议先跑通再深入，因为只有环境跑通了，才能长按Ctrl跳进源码里打断点。

调试时，我习惯在IDEA里直接运行main方法，而不是通过start-dfs.sh启动。比如我想看DFSClient的写路径，就在IDEA里新建一个Java类，main方法里写FileSystem.get(conf).create(...)，然后直接把断点打在DFSClient.primitiveCreate方法上。因为本地客户端连的是伪分布式的NameNode进程，所以服务端NameNode需要单独启动，但我可以给NameNode的启动类加上-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005，然后用IDEA的Remote Debug连接，两个进程都能断点，交互起来非常直观。

5.3 三个提高调试效率的实践技巧

第一，善用日志级别。Hadoop的日志配置走log4j.properties，正常跑任务时INFO级别看不到关键细节，建议调试期间把org.apache.hadoop.hdfs和org.apache.hadoop.yarn相关包设为DEBUG。如果嫌日志刷屏，只针对某个不稳定的类开DEBUG，比如org.apache.hadoop.hdfs.DFSOutputStream，这一步就能让你看到packet发送的完整过程。

第二，用MiniDFSCluster写单测。如果你不想启动完整伪分布式环境，Hadoop源码自带测试工具类MiniDFSCluster，它能在本地进程中拉起最小可用的NameNode和DataNode。配合JUnit写一个几十行的测试，把断点打断点的地方放在源码里，跑起来比部署伪分布式更快。

第三，善用IDEA的调用层次和书签功能。看一个核心方法时，按Ctrl+Alt+H查看方法的调用者，按Ctrl+H查看类的继承关系。我会在关键方法上打书签，例如DataStreamer.run、ShuffleSchedulerImpl.run、RMAppImpl.handle，这样在多个模块之间来回切换时不会迷路。

6. 源码排查笔记：我踩过的坑和调试记录

6.1 版本对不上，调试时对牛弹琴

我最早啃源码时犯过一个很傻的错误：用的是网上教程对应的Hadoop 2.6源码，但本地跑的是Hadoop 3.3集群，结果我在IDEA里打断点的类方法和线上日志对不上，很多类在3.x中已经被重命名了，比如org.apache.hadoop.hdfs.protocol.Block的位置、DFSOutputStream内部类的结构都变了。

这个问题的根源在于：Hadoop各版本之间的差异非常大，尤其是3.x引入的hadoop-hdfs-client模块拆分，客户端类全部挪到了新模块。排查问题时一定要先确认线上版本，再下载对应tag的源码。我现在的习惯是：在IDEA里用Git模块随时切换分支，本地同时保存2.x和3.x两套源码目录，哪个集群出问题就切到哪个版本看，避免版本混淆。

6.2 编译太慢、失败，怎么加速

Hadoop源码编译是很多人的第一道坎。最常见的失败有三类：

• 依赖下载失败。解决方案是配置阿里云或清华的Maven仓库镜像，同时把.m2/settings.xml里的mirrorOf设为*，注意Hadoop编译会用到snapshot依赖，镜像要支持snapshot更新。
• Protobuf版本问题。这个问题前面提过，按官方要求装2.5.0就好。装完后确认protoc --version输出正确。
• native模块编译失败。如果不需要C扩展，可以跳过native编译相关参数，只编Java模块。我在机器上试过去掉-Pdist直接用mvn package -DskipTests，编译速度会明显提升。

首次编译时间较长，我一般会开多个终端，一个跑Maven，一个准备配置文件和测试数据，避免干等。另外，把Maven的本地仓库缓存下来，以后换版本编译会快很多。

6.3 源码阅读顺序的三条建议

如果你从头开始读，不要按字母顺序读包名，而是按下面三条线走：

一条是从RPC入手。先读org.apache.hadoop.ipc包里的RPC类和Server类，理解Hadoop RPC的模型，之后看任何组件之间的交互都会轻松很多。

一条是从启动流程入手。无论是NameNode、DataNode还是ResourceManager，都从main方法开始跟一遍serviceInit和serviceStart，把启动过程当作主线，遇到新类再临时扩展。

一条是从线上故障入手。比如你遇到NameNode频繁FullGC，就去读FSNamesystem里与目录树和块管理相关的类；遇到Shuffle慢，就去读ShuffleSchedulerImpl。这个方法见效最快，也最有成就感。

6.4 面试场景下的源码问题清单

最后整理一份面试常问的源码问题清单，都是我实际踩过的角度，可以直接当自查表：

• NameNode启动时FSImage和EditLog的具体加载顺序？Standby节点怎么保持元数据同步？
• HDFS写文件时，副本放置策略是怎么实现的？机架感知的代码在哪个类？
• DataStreamer线程和ResponseProcessor线程如何协作？写失败时如何容错？
• Hadoop RPC的底层模型是什么样的？动态代理和Protobuf怎么结合？
• YARN的RMAppImpl状态机有哪些状态？哪些事件触发状态转换？
• CapacityScheduler分配一个Container的具体流程是什么？
• MapTask环形缓冲区多大？什么时候触发Spill？排序发生在写缓冲区时还是Spill时？
• Reduce端Shuffle拉取Map输出的流程是怎样的？哪些参数影响拉取性能？
• 与ZooKeeper集成的HA模式下，DFSZKFailoverController如何决定主备切换？

这几个问题，每一个都能从源码里找到准确答案。能不看资料讲清楚其中任意三个，应对绝大多数大数据开发面试的源码环节已经够了。

最后再说点我自己的体会。源码阅读这件事，最大的坑不是智商，而是耐心和方法。每次只追一条链路，从一次RPC发起一路追到磁盘写入，比一次性画一张“全模块架构图”有用得多。我后来养成了一个习惯：线上出任何诡异问题，先找对应版本的源码，打断点或者加日志复现，靠猜和重启解决不了根因。这套方法同样可以迁移到其他开源框架上，几年前我读MyBatis源码时用的就是同一种“问题驱动”思路，效果完全一致。如果你正准备深入Hadoop，建议从今天遇到的第一个报错开始，打开源码，找到那个异常抛出的类，把上下文看明白，这就是最好的起点。