MapReduce剖析笔记之八: Map输出数据的处理类MapOutputBuffer分析

在上一节我们分析了Child子进程启动，处理Map、Reduce任务的主要过程，但对于一些细节没有分析，这一节主要对MapOutputBuffer这个关键类进行分析。

MapOutputBuffer顾名思义就是Map输出结果的一个Buffer，用户在编写map方法的时候有一个参数OutputCollector：

  void map(K1 key, V1 value, OutputCollector<K2, V2> output, Reporter reporter)  throws IOException;

这个OutputCollector是一个接口，典型实现是OldOutputCollector，这个类的构造方法如下：

    OldOutputCollector(MapOutputCollector<K,V> collector, JobConf conf) {
      numPartitions = conf.getNumReduceTasks();
      if (numPartitions > 0) {
        partitioner = (Partitioner<K,V>)
          ReflectionUtils.newInstance(conf.getPartitionerClass(), conf);
      } else {
        partitioner = new Partitioner<K,V>() {
          @Override
          public void configure(JobConf job) { }
          @Override
          public int getPartition(K key, V value, int numPartitions) {
            return -1;
          }
        };
      }
      this.collector = collector;
    }

可以看出，其核心是MapOutputCollector的对象，另外，在构造方法里还创建了Partitioner<K,V> partitioner对象，如果用户写了分区的自定义方法，那么通过反射即可实例化自定义类（），否则使用系统自带的类。即默认为HashPartitioner，这在前面我们已经分析过：

  public Class<? extends Partitioner> getPartitionerClass() {
    return getClass("mapred.partitioner.class",
                    HashPartitioner.class, Partitioner.class);
  }

这样的话，当用户调用OutputCollector的collect()方法的时候，获取Key对应的分区号（getPartition()）后，实际上调用的就是MapOutputCollector的collect()方法：

    public void collect(K key, V value) throws IOException {
      try {
        collector.collect(key, value, partitioner.getPartition(key, value, numPartitions));
      } catch (InterruptedException ie) {
        Thread.currentThread().interrupt();
        throw new IOException("interrupt exception", ie);
      }
    }

MapOutputCollector实际上是一个接口，实现该接口的类有MapOutputBuffer和DirectMapOutputCollector，后者用于一个作业在没有Reduce阶段时使用，让Map处理的数据直接写入HDFS，前面已经看过这段代码：

    MapOutputCollector collector = null;
    if (numReduceTasks > 0) {
      collector = new MapOutputBuffer(umbilical, job, reporter);
    } else {
      collector = new DirectMapOutputCollector(umbilical, job, reporter);
    }

典型的场合下使用的就是MapOutputBuffer的collect方法。因为用户在编写Map方法的时候，对于映射后的KV都是调用collect方法执行，因此关于KV的分区、合并、压缩、缓存、写盘等等功能都是在MapOutputBuffer的统一指挥下进行的。

明白了MapOutputBuffer的作用，我们下面分析一下MapOutputBuffer的细节。

MapOutputBuffer类里面包含的变量比较多，我们对其关键变量进行分析：

1、int partitions，分区数量，表示Map任务的输出需要分为多份，partitions的值等于job.getNumReduceTasks()，也就是等于Reduce的数量；

2、TaskReporter reporter，是一个Child子进程向父进程TaskTracker汇报状态的线程类，汇报接口使用umbilical RPC接口，这在前面各节已经多次分析过，不再赘述。

3、Class<K> keyClass和Class<K> valClass代表Map处理的Key和Value的类信息，代表用户上传的配置文件中指定的"mapred.mapoutput.key.class"和"mapred.mapoutput.value.class"

      keyClass = (Class<K>)job.getMapOutputKeyClass();
      valClass = (Class<V>)job.getMapOutputValueClass();

  public Class<?> getMapOutputKeyClass() {
    Class<?> retv = getClass("mapred.mapoutput.key.class", null, Object.class);
    if (retv == null) {
      retv = getOutputKeyClass();
    }
    return retv;
  }

  public Class<?> getMapOutputValueClass() {
    Class<?> retv = getClass("mapred.mapoutput.value.class", null,
        Object.class);
    if (retv == null) {
      retv = getOutputValueClass();
    }
    return retv;
  }

4，RawComparator<K> comparator，表示用来对Key-Value记录进行排序的自定义比较器：

  public RawComparator getOutputKeyComparator() {
    Class<? extends RawComparator> theClass = getClass("mapred.output.key.comparator.class",
            null, RawComparator.class);
    if (theClass != null)
      return ReflectionUtils.newInstance(theClass, this);
    return WritableComparator.get(getMapOutputKeyClass().asSubclass(WritableComparable.class));
  }

Map处理的输入并不排序，会对处理完毕后的结果进行排序，此时就会用到该比较器。

5，SerializationFactory serializationFactory，序列化工厂类，其功能是从配置文件中读取序列化类的集合。Map处理的输出是Key,Value集合，需要进行序列化才能写到缓存以及文件中。

6，Serializer<K> keySerializer和Serializer<V> valSerializer分别用于对Map后的Key和Value进行序列化。其创建来自序列化工厂类：

      keySerializer = serializationFactory.getSerializer(keyClass);
      keySerializer.open(bb);
      valSerializer = serializationFactory.getSerializer(valClass);
      valSerializer.open(bb);

这里又涉及一个变量bb，其定义是：BlockingBuffer bb = new BlockingBuffer()

BlockingBuffer是MapOutputBuffer的一个内部类，继承于java.io.DataOutputStream，keySerializer和valSerializer使用BlockingBuffer的意义在于将序列化后的Key或Value送入BlockingBuffer。在其serialize序列化方法中，将可序列化的对象（实现Writable接口的对象）序列化后写入流，此处这个流也就是BlockingBuffer：

    public void serialize(Writable w) throws IOException {
      w.write(dataOut);
    }

Writable是个接口，w.write方法又有什么实现呢？取决于KV类型。Hadoop中需要序列化的对象（包括输入输出Key，Value都必须是可序列化的）继承于Writable接口，该接口提供两个方法：读和写：

public interface Writable {

  void write(DataOutput out) throws IOException;

  void readFields(DataInput in) throws IOException;
}

Hadoop内也有一些典型的实现，比较典型的比如IntWritable，其实现就是调用java.io.DataInput中的方法：

  public void readFields(DataInput in) throws IOException {
    value = in.readInt();
  }

  public void write(DataOutput out) throws IOException {
    out.writeInt(value);
  }

因此，当对Key、Value进行序列化的时候，实际上是调用如IntWritable（假如Key,Value类型是整型）的write方法，该方法又是反过来，调用DataOutput的writeInt方法。

在此处，BlockingBuffer内部又引入一个类：Buffer，也是MapOutputBuffer的一个内部类，继承于java.io.OutputStream。为什么要引入两个类呢？BlockingBuffer和Buffer有什么区别？初步来看，Buffer是一个基本的缓冲区，提供了write、flush、close等方法，BlockingBuffer提供了markRecord、reset方法，处理Buffer的边界等一些特殊情况，是Buffer的进一步封装，可以理解为是增强了Buffer的功能。Buffer实际上最终也封装了一个字节缓冲区，即后面我们要分析的非常关键的byte[] kvbuffer，基本上，Map之后的结果暂时都会存入kvbuffer这个缓存区，等到要慢的时候再刷写到磁盘，Buffer这个类的作用就是对kvbuffer进行封装，比如在其write方法中存在以下代码：

public synchronized void write(byte b[], int off, int len)
{
        spillLock.lock();
        try {
          do {
。。。。。。。。
             } while (buffull && !wrap);
          } finally {
          spillLock.unlock();
          }
        // here, we know that we have sufficient space to write
        if (buffull) {
          final int gaplen = bufvoid - bufindex;
          System.arraycopy(b, off, kvbuffer, bufindex, gaplen);
          len -= gaplen;
          off += gaplen;
          bufindex = 0;
        }
        System.arraycopy(b, off, kvbuffer, bufindex, len);
        bufindex += len;
      }
}

上面的System.arraycopy就是将要写入的b（序列化后的数据）写入到kvbuffer中。关于kvbuffer，我们后面会详细分析，这里需要知道的是序列化后的结果会调用该方法进一步写入到kvbuffer也就是Map后结果的缓存中，后面可以看见，kvbuffer写到一定程度的时候（80%），需要将已经写了的结果刷写到磁盘，这个工作是由Buffer的write判断的。在kvbuffer这样的字节数组中，会被封装为一个环形缓冲区，这样，一个Key可能会切分为两部分，一部分在尾部，一部分在字节数组的开始位置，虽然这样读写没问题，但在对KeyValue进行排序时，需要对Key进行比较，这时候需要Key保持字节连续，因此，当出现这种情况下，需要对Buffer进行重启（reset）操作，这个功能是在BlockingBuffer中完成的，因此，Buffer相当于封装了kvbuffer，实现环形缓冲区等功能，BlockingBuffer则继续对此进行封装，使其支持内部Key的比较功能。本质上，这个缓冲区需要是一个Key-Value记录的缓冲区，而byte[] kvbuffer只是一个字节缓冲区，因此需要进行更高层次的封装。比如：1，到达一定程度需要刷写磁盘；2，Key需要保持字节连续等等。

那么，上面write这个方法又是什么时候调用的呢？实际上就是MapOutputBuffer的collect方法中，会对KeyValue进行序列化，在序列化方法中，会进行写入：

    public void serialize(Writable w) throws IOException {
      w.write(dataOut);
    }

此处的dataout就是前面keySerializer.open(bb)这一方法中传进来的，也就是BlockingBuffer（又封装了Buffer）：

    public void open(OutputStream out) {
      if (out instanceof DataOutputStream) {
        dataOut = (DataOutputStream) out;
      } else {
        dataOut = new DataOutputStream(out);
      }
    }

因此，当执行序列化方法serialize的时候，会调用Buffer的write方法，最终将数据写入byte[] kvbuffer。

7，CombinerRunner<K,V> combinerRunner，用于对Map处理的输出结果进行合并处理，减少Shuffle网络开销。CombinerRunner是一个抽象类，根据新旧API的不同，有两种实现：OldCombinerRunner、NewCombinerRunner。这两个类里面都有一个combine方法，实现KeyValue的合并。以OldCombinerRunner为例，其combine方法如下：

    protected void combine(RawKeyValueIterator kvIter,
                           OutputCollector<K,V> combineCollector
                           ) throws IOException {
      Reducer<K,V,K,V> combiner =
        ReflectionUtils.newInstance(combinerClass, job);
      try {
        CombineValuesIterator<K,V> values =
          new CombineValuesIterator<K,V>(kvIter, comparator, keyClass,
                                         valueClass, job, Reporter.NULL,
                                         inputCounter);
        while (values.more()) {
          combiner.reduce(values.getKey(), values, combineCollector,
              Reporter.NULL);
          values.nextKey();
        }
      } finally {
        combiner.close();
      }
    }

从其代码可以看出，首先根据combinerClass利用反射机制创建了一个combiner对象，实际上这个对象就是一个遵从Reducer接口的对象。之后利用CombineValuesIterator对KV进行逐一提取，执行其reduce方法，CombineValuesIterator在上一节看过，是ValuesIterator的子类，可以看出，combiner实现的就是本Map任务内的、局部的reduce。

8，CombineOutputCollector<K, V> combineCollector，即Combine之后的输出对象。其创建代码为：

      if (combinerRunner != null) {
        combineCollector= new CombineOutputCollector<K,V>(combineOutputCounter, reporter, conf);
      } else {
        combineCollector = null;
      }

其定义里面有一个Writer对象：

  protected static class CombineOutputCollector<K extends Object, V extends Object>
  implements OutputCollector<K, V> {
    private Writer<K, V> writer;
。。。

当启用了Combine功能后，会调用上面的combine方法进行（reduce）操作后再写入文件(reduce里会使用CombineOutputCollector对象进行collect，见下面Reducer接口的reduce定义代码)，这里的Writer就是写入文件的作用。如果没有启用Combine功能呢，则直接利用Writer写文件。

  void reduce(K2 key, Iterator<V2> values,
              OutputCollector<K3, V3> output, Reporter reporter)
    throws IOException;

9，CompressionCodec codec，用于对Map的输出进行压缩。其创建代码为：

      // compression
      if (job.getCompressMapOutput()) {
        Class<? extends CompressionCodec> codecClass =
          job.getMapOutputCompressorClass(DefaultCodec.class);
        codec = ReflectionUtils.newInstance(codecClass, job);
      }

是否对Map的输出进行压缩决定于变量"mapred.compress.map.output"，默认不压缩。

10，int[] kvoffsets，int[] kvindices，byte[] kvbuffer。三者是为了记录KV缓存的数据结构，kvBuffer按照Key-Value（序列化后）的顺序记录，前面说的BlockingBuffer和Buffer封装的底层数据结构就是kvbuffer（它们都是内部类，可以处理MapOutputBuffer中的变量）；kvindices记录了一堆kvindex，每个kvindex包含三个信息：分区号、Key和Value在kvbuffer中的位置；为了对kvindices中的kvindex进行定位，于是有了第三个结构kvoffsets，只记录每个kvindex的位置（一个整数即可），另外一个作用是当超过了一定数量后，则会触发Spill操作，Spill的中文指溢出，大致的含义是当缓存放慢了，就溢出写到磁盘上去。三者关系的示意图如下：

上面的结构有什么好处呢？我们知道，Map输出的结果是一堆KV对，可以不断地存入kvbuffer中，但怎么按照分区号提取相应的KV对呢？kvindices就是干这个的，通过解析这个数组，就可以得到某个分区的所有KV的位置。之所以需要按照分区号提取，是因为Map的输出结果需要分为多份，分别送到不同的Reduce任务，否则还需要对key进行计算才得到分区号，除了提高速度之外，更关键的作用是排序，Map处理后的结果有多份，每一份默认是按照分区号对KV记录进行排序的，但是在kvbuffer中源源不断过来的KeyValue序列并没有什么顺序，为此，当对kvbuffer中的某一个分区的KeyValue序列进行排序时，排序结果只需要将kvoffsets中对应的索引项进行交换即可（后面会看到这一详细过程），保证kvoffsets中索引的顺序其实就想记录的KeyValue的真实顺序。换句话说，我们要对一堆对象进行排序，实际上只要记录他们索引的顺序（类似于指针数组，每个指针指向一个对象）即可，原始记录保持不动（因为空间很大），而kvoffsets就是一堆整数的序列，交换起来快得多。

从上面的图可以看出，对于任意一个KeyValue记录，都会额外产生16个字节的索引开销，其中12个字节是kvindices中用于记录分区号、Key位置和Value位置（都是整型），另外4个字节是kvoffsets中的整数值。MapOutputBuffer类里也定义了几个变量用于说明上述四个变量的位置和所占字节数：

    private static final int PARTITION = 0; // partition offset in acct
    private static final int KEYSTART = 1;  // key offset in acct
    private static final int VALSTART = 2;  // val offset in acct
    private static final int ACCTSIZE = 3;  // total #fields in acct
    private static final int RECSIZE =
                       (ACCTSIZE + 1) * 4;  // acct bytes per record

ACCT表示kvindices中的一个kvindex，ACCTSIZE也就是3个字节，这里的命名稍微有些不规范，RECSIZE称为记录大小，这里的记录指的就是对每个KV索引的大小，即3+1=4个字节。

kvbuffer、kvindices、kvoffsets三个数组的大小之和由参数"io.sort.mb"指定，默认是sortmb=100，于是maxMemUsage = sortmb << 20，即100MB（1MB=2^20B），maxMemUsage是MapOutputBuffer所占内存的主要部分。这100MB中，有一部分拿出来存储kvindices和kvoffsets，占比为"io.sort.record.percent"，默认是recper=0.05，即5MB左右用来（需要是16的整数倍）存储kvindices和kvoffsets。另外95MB左右用以存储kvbuffer。

在kvbuffer中，如果达到了一定容量，需要Spill到磁盘上，这个门限由参数"io.sort.spill.percent"指定，默认是spillper=0.8。softBufferLimit这个门限就是用于记录Spill门限容量：

softBufferLimit = (int)(kvbuffer.length * spillper);

此外，除了kvbuffer增加会引起Spill之外，kvoffsets的膨胀也会引起Spill，比例也是spillper=0.8，这个门限由softRecordLimit参数记录：

softRecordLimit = (int)(kvoffsets.length * spillper);

即无论哪个到达了80%，都触发Spill。为什么到达80%就需要刷写磁盘呢？如果写满了才刷写磁盘，那么在刷写磁盘的过程中不能写入，写就被阻塞了，但是如果到了一定程度就刷写磁盘，那么缓冲区就一直有剩余空间可以写，这样就可以设计成读写不冲突，提高吞吐量。KV缓存中的最顶级索引是kvoffsets，因此当出现Spill时，需要将kvoffsets中已经记录的索引对应的KV提取出来进行写磁盘，当spill后，kvoffsets又成为空数组。我们粗略想一下，kvoffsets不断地往后增加记录，到达一定程度后，触发Spill，于是从头（即下标0）到当前位置（比如称为kvindex）的所有索引对应的KV都写到磁盘上，Spill结束（此时假定KV缓存写入暂停）后，又从下标0开始增加记录，这种形式会有什么问题？

一个比较大的问题是Spill的时候，意味着有个用户在读取kvoffsets从0-kvindex的数据，这个时候这部分数据就不能写，因为下一次写要从下标0开始，这样就需要对kvoffsets加锁才行，否则会引起读错误，这样的话，还是难以实现读写并行。为了解决这种加锁引发的性能问题，典型方法就是采用环形缓冲区。kvoffsets看做一个环形数组，Spill的时候，只要kvbuffer和kvoffsets还没有满（能容纳新的KeyValue记录和索引），kvoffsets仍然可以继续往后面写；同理，kvbuffer也是一个环形缓冲区，这样的话，如果我们把spill到磁盘这一过程用另外一个线程实现（Hadoop里面确实也是这么做的），那么读写可以不冲突，提高了性能。

实现环形缓冲区的典型方法也是Hadoop中采用的方法。以kvoffsets为例，一共有三个变量：kvstart、kvindex和kvend。kvstart表示当前已写的数据的开始位置，kvindex表示写一个下一个可写的位置，因此，从kvstart到（kvindex-1）这部分数据就是已经写的数据，另外一个线程来Spill的时候，读取的数据就是这一部分。而写线程仍然从kvindex位置开始，并不冲突（如果写得太快而读得太慢，追了一圈后可以通过变量值判断，也无需加锁，只是等待）。

举例来说，下面的第一个图表示按顺时针往kvoffsets里面加入索引，此时kvend=kvstart，但kvindex递增；当触发Spill的时候，kvend=kvindex，Spill的值涵盖从kvstart到kvend-1区间的数据，kvindex不影响，继续按照进入的数据递增；当进行完Spill的时候，kvindex增加，kvstart移动到kvend处，在Spill这段时间，kvindex可能已经往前移动了，但并不影响数据的读取，因此，kvend实际上一般情况下不变，只有在要读取环形缓冲区中的数据时发生一次改变（即设置kvend=kvindex）：

在源代码的解释中，kvstart是记录spill的起始位置，kvend是记录collectable的起始位置，kvindex是记录collected的结束位置，collect即前面说过的map方法产生的KV对需要写入缓冲区，从生产者-消费者角度来看，collect就是这个环形缓冲区的生产者，或者叫写线程；spill是这个环形缓冲区的消费者，或者叫读线程。这样看来，spill每次消费多少数据实际上可以与上面的图有所差别，比如目前只Spill从1-8这个区间的数据，那么之后kvstart设置为9所在的位置即可，下一次Spill即从9开始。

上图反映了环形缓冲区的利用，对于kvbuffer的使用原理也一样，同样存在三个变量：bufstart、bufmark（为什么不叫bufindex呢？下面分析）、bufend。对于kvoffsets来说，有三个变量就可以实现环形缓冲区，但对于kvbuffer来说，三个变量还不够，这是为什么呢？因为kvoffsets里面都是以整数为基本单位，每个整数占用4个字节，kvoffsets的类型是int[]，不会出现什么问题，使用起来也很方便。但是kvbuffer就不一样，其定义为byte[]，但是一个Key-Value的长度是不固定的，虽然形式上环形缓冲区不存在头部和尾部的概念，但其物理上缓冲区还是存在头和尾，并不是物理连续的，按理来说，对于Key-Value的操作，只要把接口封装好，让上层应用看起来是连续的即可。但Hadoop里面对Key的比较设计成逐字节比较，其定义为：

public interface RawComparator<T> extends Comparator<T> {

  public int compare(byte[] b1, int s1, int l1, byte[] b2, int s2, int l2);

}

为什么不设计成compare(Key1 key, Key2 key)这种形式呢？这不是更直观吗，个人理解，排序是对Map后的Key-Value缓冲区操作的，如果将Key、Value都看做JAVA对象，设计Object的排序，排序的速度要比byte这个层次更差，因为封装的层次更高了，所以，将所有key全部序列化后存入缓冲区，然后对其进行排序操作会更快，这样的话，就需要Key在物理上（实际上是JAVA字节数组这个层次，当然不是指硬盘的磁道等等更底层的层次）保持连续，毕竟，按Key排序作为MapReduce中一个很核心的东西，这样做还是值得的。为此，在缓存里面就需要保证Key的连续性，自然，当往缓冲区里面写入一个会超越边界的key的时候，就需要进行特殊处理，这种处理由BlockingBuffer实现，称为reset，当检测到这种情况的时候，就调用一下reset，代码如下：

        // serialize key bytes into buffer
        int keystart = bufindex;
        keySerializer.serialize(key);
        if (bufindex < keystart) {
          // wrapped the key; reset required
          bb.reset();
          keystart = 0;
        }

所谓reset，其实就是把跨越边界（如何判断：写入一个Key之后的bufindex还比写之前的bufindex位置还小）的Key的尾部拷贝一下到头部，使其连续。bufindex的含义和前面kvindex类似，代表了下一个可以写的位置。如下图所示，红色表示已经写入的KeyValue记录，蓝色表示要写入的下一个Key，在调用Buffer的write方法后，如果发现跨越了边界（bufindex变小了），则将尾部的那块蓝色区域拷贝到头部，头部那块蓝色区域往后挪，形成一个整体的Key，尾部蓝色那块区域空出来的就无效了，在读的时候就需要跳过。这样就需要多个变量来记录位置信息，除了bufindex，bufvoid就表示这个缓冲区在读取的时候需要停止的位置，因为这个位置不一定是缓冲区的最大长度，但肯定只会在缓冲区的尾巴处出现，所以需要1个变量来记录；这里还新增了一个bufmark，其含义是一个KeyValue的结尾处，因为kvoffsets里面不存在这个问题，每个整数值就是一个基本单元，但一个KeyValue长度不一，需要用bufmark记录下来。每当序列化写入一个Key-Value对，就更新这个数值。记下来的目的之一比如说下面这种情况，需要将尾部的蓝色区域拷贝到头部的时候，就需要知道尾部这一段有多少个字节，bufvoid-bufmark就等于尾部这段蓝色区域的长度。

理解了上面的变量，reset的代码就比较简单了，如下，其中headbytelen就是尾部蓝色区域的长度，另外，在下面的代码中，如果拷贝后的key长度超过了bufstart，也就是空间不够了，那么就会直接把key直接输出，此时bufindex置为0：

      protected synchronized void reset() throws IOException {
        int headbytelen = bufvoid - bufmark;
        bufvoid = bufmark;
        if (bufindex + headbytelen < bufstart) {
          System.arraycopy(kvbuffer, 0, kvbuffer, headbytelen, bufindex);
          System.arraycopy(kvbuffer, bufvoid, kvbuffer, 0, headbytelen);
          bufindex += headbytelen;
        } else {
          byte[] keytmp = new byte[bufindex];
          System.arraycopy(kvbuffer, 0, keytmp, 0, bufindex);
          bufindex = 0;
          out.write(kvbuffer, bufmark, headbytelen);
          out.write(keytmp);
        }
      }

12，SpillThread spillThread，这是一个线程对象，继承于Thread：

    private final SpillThread spillThread = new SpillThread();

其作用就是当kvbuffer或kvoffsets超过80%以上，将触发该线程将kvbuffer中的数据写入到磁盘。读写分别是两个线程。触发Spill的代码为：

    private synchronized void startSpill() {
      LOG.info("bufstart = " + bufstart + "; bufend = " + bufmark + "; bufvoid = " + bufvoid);
      LOG.info("kvstart = " + kvstart + "; kvend = " + kvindex + "; length = " + kvoffsets.length);
      kvend = kvindex;
      bufend = bufmark;
      spillReady.signal();
    }

从这里可以看出，触发Spill时，正是我们前面分析过的，需要执行这个动作：kvend = kvindex、bufend=bufmark。注意，写入磁盘的数据实际上只是kvbuffer里面的记录，kvoffsets索引只是同步更新，后面我们会看到，跟kvbuffer同时写入的实际上是有一个索引数据的，但不是上面提到的这几个。spillReady是一个java.util.concurrent.locks.Condition对象，环形缓冲区的读写线程之间的同步使用JAVA中提供的方法实现，涉及到以下变量：

    private final ReentrantLock spillLock = new ReentrantLock();
    private final Condition spillDone = spillLock.newCondition();
    private final Condition spillReady = spillLock.newCondition();

我们前面分析过，环形缓冲区在一个生产者和一个消费者条件下，双方对读写数据是不需要加锁的，因为读写数据不会位于同一个位置，大家处理的是整个环上不同的部分，那么这里引入锁的目的是什么呢？一种情况自然是当缓冲区满了的时候，此时可以使用锁，理论上也可以判断变量，看看是否写满等等，但无论如何此时写线程需要阻塞，如果写线程每过一段时间来扫描一下是否可以写，这种方式造成的延时跟另一个线程直接发信号通知比起来更慢；另外，读写双方涉及到三个变量kvstart、kvend、kvindex的修改。也就是说，当写完毕，或者读完毕时需要修改变量的时候，加锁保证了变量的一致性。这里不使用synchronized这种传统的同步方法，主要原因是synchronized不够灵活，扩展性不好，JAVA中提供了另外一种机制，即ReentrantLock等典型锁类。这种方式灵活性更好，因为锁只是一个对象（synchronized是一个关键字，用语法来支持同步）。ReentrantLock的含义是可重入锁，因为Re-entrant就是可以重新进入的意思，什么叫可重入呢？比如一个函数被递归调用，在执行这个函数代码的过程中，还没执行完毕又被再次调用，就是不断重入的意思。ReentrantLock也如此，一个线程A获得锁以后，这个线程A还可以继续再次获取这把锁，其他线程B要想获得这把锁，要么等着A把锁释放了，如果A不显式释放，但是通过发信号等待的方式，也可以间接地使得锁释放（这一点很关键）。此时，线程B就可以获得这把锁。让一个线程多次获取一把锁有什么意义呢？比如有两段代码分布在不同的地方，都加了同样的一个锁对象，某个线程则可以连续执行这两段代码，因为是一把锁。否则，执行完了第一段后，第二段就无法执行了，这样就很容易出现死锁。另外，通过发信号（而且可以有很多不同的信号）的方式释放锁，为线程在不同特定条件下释放锁提供了极大灵活性。

在线程A拿到锁之后，可以通过发送信号控制其它线程B的执行。比如A拿到了锁，但是需要等待一个条件C才能往下执行，但我又不想释放这把锁，于是可以调用一个称为C.await的方法，让线程B可以获得这把锁，去执行它的代码，当在线程B里满足了条件C，它调用C.signal这个方法，则可以让线程A的条件满足不再等待，接着往下执行（但需要线程B释放锁，或者也调用另外一个条件D的await方法）。这种同步模式比较灵活，所以一般来说，典型应用场景是两个线程共有一把ReentrantLock锁，并且有两个以上共有的条件变量Condition1、Condition2。一个线程负责执行Condition1.signal和Condition2.await；另一个线程负责执行Condition2.signal和Condition1.await。

比如上面的例子就创建了两种信号：spillDone和spillReady，它们的逻辑如下：

1）对于写线程来说，如果写满了，就调用spillDone.await等待spillDone信号；否则不断往缓冲区里面写，到了一定程度，就发送spillReady.signal这个信号给读线程，发完这个信号后如果缓冲区没满，就释放锁继续写（这段代码无需锁），如果满了，就等待spillDone信号；

2）对于读线程来说，在平时调用spillReady.await等待spillReady这个信号，当读取之后（此时写线程要么释放锁了，要么调用spillDone.await在等待了，读线程肯定可以获得锁），则把锁释放掉，开始Spill（这段代码无需锁），完了读线程再次获取锁，修改相应参数，发送信号spillDone给写线程，表明Spill完毕。

上面的线程同步模式+环形缓冲区的使用是经典案例，值得仔细学习。

作为SpillThread这个消费者、读线程而言，主要代码是在其run方法内：

      public void run() {
        spillLock.lock();
        spillThreadRunning = true;
        try {
          while (true) {
            spillDone.signal();
            while (kvstart == kvend) {
              spillReady.await();
            }
            try {
              spillLock.unlock();
              sortAndSpill();
            } catch (Exception e) {
             。。。
            } finally {
              spillLock.lock();
              if (bufend < bufindex && bufindex < bufstart) {
                bufvoid = kvbuffer.length;
              }
              kvstart = kvend;
              bufstart = bufend;
            }
          }
        } catch (InterruptedException e) {
          ........
        } finally {
          spillLock.unlock();
          spillThreadRunning = false;
        }
      }

MapOutputBuffer的collect方法是生产者、写线程，主要代码即在该方法内，其中startSpill前面已经看过，主要是改变kvend值以及发送spillReady信号：kvnext是kvindex加1，用于判断是否写满，如果kvnext==kvstart，表示写满，布尔变量kvfull则为true。

kvsoftlimit是是否超过Spill门限的标志。

    public synchronized void collect(K key, V value, int partition
                                     ) throws IOException {
      final int kvnext = (kvindex + 1) % kvoffsets.length;
      spillLock.lock();
      try {
        boolean kvfull;
        do {
          // sufficient acct space
          kvfull = kvnext == kvstart;
          final boolean kvsoftlimit = ((kvnext > kvend)
              ? kvnext - kvend > softRecordLimit
              : kvend - kvnext <= kvoffsets.length - softRecordLimit);
          if (kvstart == kvend && kvsoftlimit) {
            startSpill();
          }
          if (kvfull) {
            try {
              while (kvstart != kvend) {
                reporter.progress();
                spillDone.await();
              }
            } catch (InterruptedException e) {
。。。。。。。。
            }
          }
        } while (kvfull);
      } finally {
        spillLock.unlock();
      }
。。。。
写数据
。。。

13，ArrayList<SpillRecord> indexCacheList，这个是SpillRecord的数组，SpillRecord里面缓存的是一个一个的记录，所以并不是一整块无结构字节流，而是以IndexRecord为基本单位组织起来 的，IndexRecord非常简单，描述了一个记录在缓存中的起始偏移、原始长度、实际长度（可能压缩）等信息。SpillRecord里面放了一堆 IndexRecord，并有方法可以插入记录、获取记录等。IndexRecord的定义很简单如下：

class IndexRecord {
  long startOffset;
  long rawLength;
  long partLength;

  public IndexRecord() { }

  public IndexRecord(long startOffset, long rawLength, long partLength) {
    this.startOffset = startOffset;
    this.rawLength = rawLength;
    this.partLength = partLength;
  }
}

SpillRecord的意义在什么地方呢？当kvbuffer触发Spill的时候，会将kvbuffer的记录写入到磁盘（实际上还会包括记录的长度等信息）。Spill结束后，会生成一个spill文件，这个文件内部包含很多分区的数据，但是是排序过的KeyValue数据（关于排序后面会讨论），分为两层，首先是对分区号进行排序，其次是在一个分区号内，按照Key的大小进行排序，因此Spill文件是一个分区的数据接着一个分区的数据，且每个分区里面的Key-Value都已经按照Key的顺序进行排列；SpillRecord就记录了每个分区数据在文件中的起始位置、长度、以及压缩长度，这些内容表示成IndexRecord。一个IndexRecord记录的是一个分区的位置信息，因为一个Spill文件包含N个分区，于是就会有N个IndexRecord，这N个IndexRecord记录在一个SpillRecord对象中。SpillRecord里面有两个变量：ByteBuffer buf，以及LongBuffer entries。ByteBuffer和LongBuffer都是java.nio里面提供的类，ByteBuffer是IndexRecord存储的真正区域，LongBuffer就是对ByteBuffer进行了一点接口封装，把它当做一个存储Long型的Buffer。这种概念类似于数据库里面的视图跟表的关系一样。因为IndexRecor里面包含三个Long型变量，每个8字节，因此一个 IndexRecord记录占用24字节，这就是MapTask.MAP_OUTPUT_INDEX_RECORD_LENGTH这个变量指定的。分区数量是numPartitions，因此一个文件需要numPartitions*24来记录，这也就是一个SpillRecord的大小，每个文件都有一个SpillRecord，因为Spill会有很多次，每次都写成一个文件，所以会有很多个Spill文件，对应于很多个SpillRecord，这很多个SpillRecord即为ArrayList<SpillRecord> indexCacheList。

为什么要把各个分区数据的位置记录下来呢？因为MapReduce对Map后的结果会按照分区号对Key-Value进行排序，假定最终生成了10个Spill文件，需要按照分区，将每个分区对应的数据全部拿出来进行归并排序（Merger），这种排序在Map这一端就有两个阶段，首先是一个Spill文件内部要按照分区对KV排好序（kvoffsets排好序按照顺序写进Spill文件），之后还得把10个Spill文件内部的KV拿过来归并排序。另外，实际上在Reduce端还会进行归并排序，因为我们目前讨论的都只是在单个Map任务内的排序，Reduce之前还会把各个Map任务排好序的结果进行再次归并排序，可见，有三种归并排序，MapReduce中的排序就是不断地进行归并排序的过程。

另外，除了将kvbuffer的数据写进文件，SpillRecord的信息也会写到文件里，作为后面多个Spill文件归并的索引。如果不写入这个信息，怎么知道Spill文件里面的KeyValue是属于哪个分区呢？如果没有这个信息，也就无法实现后面的归并。

14，IndexedSorter sorter，理解了上面的过程，这个变量就容易了，如何对map后的KeyValue进行排序就取决于该对象。IndexedSorter是一个接口，用户可以实现自定义的方法，其创建代码如下：

      sorter = ReflectionUtils.newInstance(job.getClass("map.sort.class", QuickSort.class, IndexedSorter.class), job);

可以看出，如果用户没有配置，默认就使用Hadoop自带的QuickSort类，即快速排序。另外，排序的规则是对Key进行比较，这里采用的比较对象就是RawComparator<K> comparator。

排序的对象是一个IndexedSortable接口对象，MapOutputBuffer实现了这个接口中的compare和swap方法，compare方法即比较两个Key的大小，返回整数：

    public int compare(int i, int j) {
      final int ii = kvoffsets[i % kvoffsets.length];
      final int ij = kvoffsets[j % kvoffsets.length];
      // sort by partition
      if (kvindices[ii + PARTITION] != kvindices[ij + PARTITION]) {
        return kvindices[ii + PARTITION] - kvindices[ij + PARTITION];
      }
      // sort by key
      return comparator.compare(kvbuffer,
          kvindices[ii + KEYSTART],
          kvindices[ii + VALSTART] - kvindices[ii + KEYSTART],
          kvbuffer,
          kvindices[ij + KEYSTART],
          kvindices[ij + VALSTART] - kvindices[ij + KEYSTART]);
    }

可见，这个比较分为两个层次，首先是分区号的排序，在分区号相同条件下，再进行Key的比较。怎么进行Key的比较呢？每个kvoffsets里面就一个字节，记录了对应的kvindex，kvindex又有3字节，分别是分区号、key在kvbuffer的位置、value在kvbuffer的位置，所以其比较就是首先获得i、j对应的两个kvindex，最终调用RawComparator<K> comparator的compare方法，比较两个Key值的大小，key在kvbuffer中的位置是在kvindices[ii + 1]开始到kvindices[ii + 2]之间，另一个key的位置是在kvbuffer的kvindices[ij + 1]到kvindices[ij + 2]之间。前面已经对kvbuffer、kvindices、kvoffsets进行了详细分析，这里也就比较简单了。

在排序的过程中会进行交换，kvbuffer和kvindices都保持不变，只有kvoffsets进行了交换：

    public void swap(int i, int j) {
      i %= kvoffsets.length;
      j %= kvoffsets.length;
      int tmp = kvoffsets[i];
      kvoffsets[i] = kvoffsets[j];
      kvoffsets[j] = tmp;
    }

因为按照排序原则，如果不是同一个分区的KV，那就不用排序；如果是同一个分区的KV，那就进行排序，所以最终的排序只在kvoffsets中进行交换，当交换完毕后，排序也就结束。要写入文件时，只要按照kvoffsets的顺序将对应的kvbuffer中的数据写入文件即可。

15，上面对MapOutputBuffer涉及的变量进行了分析，其原理也基本涵盖在上面的各个分析之中，下面我们来看一看collect方法的过程。

该方法的声明为：

    public synchronized void collect(K key, V value, int partition
                                     ) throws IOException

其作用就是对map之后的KeyValue进行处理。

首先获得kvoffsets中的kvindex的下一个位置，用于判断kvoffsets是否写满：

final int kvnext = (kvindex + 1) % kvoffsets.length;

因为kvindex代表了下一个可写的位置，如果再下一个已经等于kvstart，那么说明已经写满了，需要等待SpillThread处理。

于是设置了一个变量kvfull = kvnext == kvstart;即二者相等时即为true。

要判断是否Spill，加锁：

spillLock.lock();

之后判断是否应该Spill：

          final boolean kvsoftlimit = ((kvnext > kvend)
              ? kvnext - kvend > softRecordLimit
              : kvend - kvnext <= kvoffsets.length - softRecordLimit);

之所以会有两种情况，是因为这是一个环形缓冲区，可能kvnext大于kvend（没有Spill时等于kvstart）很多，也可能kvnext已经绕回到了0那个位置，不管怎样，如果两者的差距（绝对值）大于softRecordLimit（80%的kvoffsets），则kvsoftlimit=true。

如果kvstart==kvend，表示此时没有处于Spill（前面分析过，Spill时会将kvend设置为kvindex），并且如果满足了kvsoftlimit，则进行Spill，向SpillThread发信号：

          if (kvstart == kvend && kvsoftlimit) {
            LOG.info("Spilling map output: record full = " + kvsoftlimit);
            startSpill();
          }

发完信号后不一定可以写了，因为此时缓冲区说不定满了，所以如果满了，就等待SpillDone信号，这个信号是SpillThread发过来的：

          if (kvfull) {
            try {
              while (kvstart != kvend) {
                reporter.progress();
                spillDone.await();
              }
            } catch (InterruptedException e) {
              throw (IOException)new IOException(
                  "Collector interrupted while waiting for the writer"
                  ).initCause(e);
            }
          }

好了，如果跳出来了，说明此时缓冲区可写了，于是把锁释放，准备往缓冲区里面写数据（再重复一遍，读写数据不用加锁）：

finally {
        spillLock.unlock();
      }

要写入key，首先要将其序列化：

        int keystart = bufindex;
        keySerializer.serialize(key);

之后，因为有可能key序列化后超出了kvbuffer的边界，进行一些边界条件处理，这一边界问题在前面已经分析过：

        if (bufindex < keystart) {
          // wrapped the key; reset required
          bb.reset();
          keystart = 0;
        }

紧接着是对value进行序列化：

        // serialize value bytes into buffer
        final int valstart = bufindex;
        valSerializer.serialize(value);
        int valend = bb.markRecord();

之后，更新kvindices,kvoffsets中的索引信息：

        // update accounting info
        int ind = kvindex * ACCTSIZE;
        kvoffsets[kvindex] = ind;
        kvindices[ind + PARTITION] = partition;
        kvindices[ind + KEYSTART] = keystart;
        kvindices[ind + VALSTART] = valstart;
        kvindex = kvnext;

此处的ind就是新的kvindex的位置，乘以3字节就等于其在kvindices中的位置。同时更新kvindices，kvindex向前移动一个字节。

于是，collect方法就结束了，KV已经被序列化进入kvbuffer了，下面看一看SpillThread涉及到的方法。

16，SpillThread在构造方法中被启动：

      spillThread.setDaemon(true);
      spillThread.setName("SpillThread");
      spillLock.lock();
      try {
        spillThread.start();
        while (!spillThreadRunning) {
          spillDone.await();
        }
      } catch (InterruptedException e) {
        throw (IOException)new IOException("Spill thread failed to initialize"
            ).initCause(sortSpillException);
      } finally {
        spillLock.unlock();
      }

进入SpillThread的run方法，该方法的处理逻辑在前面已经分析过，主要涉及的方法是sortAndSpill。

首先获得要写入的Spill文件的大小：

      //approximate the length of the output file to be the length of the
      //buffer + header lengths for the partitions
      long size = (bufend >= bufstart
          ? bufend - bufstart
          : (bufvoid - bufend) + bufstart) + partitions * APPROX_HEADER_LENGTH;

每个分区都会有一些头开销，此处为150个字节，这个与Spill文件的文件格式有关，在每个分区之前都会加入一些记录信息，这里可以看出，Spill文件里面实际上是所有分区的数据混合在一起（但是是一个分区的数据跟着另一个分区的数据）。

然后获取要写入的本地文件的文件名，注意不是HDFS文件，而是本地Linux文件：

        // create spill file
        final SpillRecord spillRec = new SpillRecord(partitions);
        final Path filename = mapOutputFile.getSpillFileForWrite(numSpills, size);
        out = rfs.create(filename);

  public Path getSpillFileForWrite(int spillNumber, long size)
      throws IOException {
    return lDirAlloc.getLocalPathForWrite(TaskTracker.OUTPUT + "/spill"
        + spillNumber + ".out", size, conf);
  }

在这时会创建一个与Spill文件对应的SpillRecord对象（输入参数为分区总数），其文件名为：

TaskTracker.OUTPUT + "/spill" + spillNumber + ".out"

TaskTracker.OUTPUT其实就是一个字符串String OUTPUT = "output"，所以Spill的文件名为output/spill2.out等，表示这个文件是第2个Spill文件（最终会有多个Spill文件，前面分析过）。

然后调用上面分析过的排序对象进行排序，实际上就是通过交换kvoffsets里面的字节达到目的：

        final int endPosition = (kvend > kvstart)
          ? kvend
          : kvoffsets.length + kvend;
        sorter.sort(MapOutputBuffer.this, kvstart, endPosition, reporter);

之后是一个大循环，对每个分区依次进行以下操作。

创建一个写文件的对象：

  writer = new Writer<K, V>(job, out, keyClass, valClass, codec, spilledRecordsCounter);

此时有两种情况，排序后的Key-Value不一定直接写入文件，如果需要在Map端进行合并（Combiner）的话，则先进行合并再写入：

我们先来看不需要合并的代码。就是一个循环：

            DataInputBuffer key = new DataInputBuffer();
            while (spindex < endPosition && kvindices[kvoffsets[spindex % kvoffsets.length] + PARTITION] == i) {
              final int kvoff = kvoffsets[spindex % kvoffsets.length];
              getVBytesForOffset(kvoff, value);
              key.reset(kvbuffer, kvindices[kvoff + KEYSTART], (kvindices[kvoff + VALSTART] - kvindices[kvoff + KEYSTART]));
              writer.append(key, value);
              ++spindex;
            }

注意while条件中只挑选那些分区号满足大循环中当前分区号的数据，获得KeyValue在kvbuffer中的位置（kvoff），然后key的值就从kvindices[kvoff + KEYSTART]到kvindices[kvoff + VALSTART]之间。KEYSTART和VALSTART是固定值1、2，我们再回顾一下，kvindices[kvoff]记录的是分区号、kvindices[kvoff + 1]记录的Key在kvbuffer中的起始位置，kvindices[kvoff + 2]记录的是Value在kvbuffer中的起始位置，于是就得到了key。

Value的获取是利用getVBytesForOffset实现的。原理也一样：

    private void getVBytesForOffset(int kvoff, InMemValBytes vbytes) {
      final int nextindex = (kvoff / ACCTSIZE == (kvend - 1 + kvoffsets.length) % kvoffsets.length)
        ? bufend
        : kvindices[(kvoff + ACCTSIZE + KEYSTART) % kvindices.length];
      int vallen = (nextindex >= kvindices[kvoff + VALSTART])
        ? nextindex - kvindices[kvoff + VALSTART]
        : (bufvoid - kvindices[kvoff + VALSTART]) + nextindex;
      vbytes.reset(kvbuffer, kvindices[kvoff + VALSTART], vallen);
    }

即nextindex要么是bufend，要么是绕一圈之后的对应值。

之后调用writer.append(key, value)写入KV即可。

如果是需要对KeyValue进行合并的，则执行combine方法：

              if (spstart != spindex) {
                combineCollector.setWriter(writer);
                RawKeyValueIterator kvIter =
                  new MRResultIterator(spstart, spindex);
                combinerRunner.combine(kvIter, combineCollector);
              }

combine方法我们前面分析过，其实就是调用了用户写的reduce方法：

    protected void combine(RawKeyValueIterator kvIter,
                           OutputCollector<K,V> combineCollector
                           ) throws IOException {
      Reducer<K,V,K,V> combiner =
        ReflectionUtils.newInstance(combinerClass, job);
      try {
        CombineValuesIterator<K,V> values = new CombineValuesIterator<K,V>(kvIter, comparator, keyClass,
                                         valueClass, job, Reporter.NULL,
                                         inputCounter);
        while (values.more()) {
          combiner.reduce(values.getKey(), values, combineCollector, Reporter.NULL);
          values.nextKey();
        }
      } finally {
        combiner.close();
      }
    }
  }

当写入Spill文件后，还需要对SpillRecord进行记录：

            // record offsets
            rec.startOffset = segmentStart;
            rec.rawLength = writer.getRawLength();
            rec.partLength = writer.getCompressedLength();
            spillRec.putIndex(rec, i);

即当前这个分区中数据的起始位置、原始长度、压缩后长度。在Writer类中，其append方法会将Key长度和Value长度都写进去：

      WritableUtils.writeVInt(out, keyLength);
      WritableUtils.writeVInt(out, valueLength);
      out.write(key.getData(), key.getPosition(), keyLength);
      out.write(value.getData(), value.getPosition(), valueLength);

使用的VInt即变长整数编码，这种编码方式类似于ProtoBuf（但是否完全一样还没分析），见我写的另外一篇介绍ProtocolBuffer的博客。可以看出，KeyValue的记录加上了Key的长度、Value的长度两个信息，如果不加无法区分Key、Value的边界。

注意到，如果设置了压缩，则在Writer构造方法里将写入流对象换成另外一个：

      if (codec != null) {
        this.compressor = CodecPool.getCompressor(codec);
        this.compressor.reset();
        this.compressedOut = codec.createOutputStream(checksumOut, compressor);
        this.out = new FSDataOutputStream(this.compressedOut,  null);
        this.compressOutput = true;
      } else {
        this.out = new FSDataOutputStream(checksumOut,null);
      }

按照上面的过程，对每个分区进行循环即可不断地写入到Spill文件，可见，一个Spill文件，比如output/spill2.out这个文件，其内容是一个分区跟着一个分区，每个分区里面的数据都经过了排序。每次触发Spill的时候就会生成一个文件。如：

output/spill1.out、output/spill2.out、output/spill3.out、....

写完了Spill文件后，还会把SpillRecord的内容写入成一个Spill索引文件，不过这个写不是一个Spill文件就对应于一个索引文件，而是超过了一个界限（1MB）再写入：

        if (totalIndexCacheMemory >= INDEX_CACHE_MEMORY_LIMIT) {
          // create spill index file
          Path indexFilename =
              mapOutputFile.getSpillIndexFileForWrite(numSpills, partitions
                  * MAP_OUTPUT_INDEX_RECORD_LENGTH);
          spillRec.writeToFile(indexFilename, job);
        } else {
          indexCacheList.add(spillRec);
          totalIndexCacheMemory +=
            spillRec.size() * MAP_OUTPUT_INDEX_RECORD_LENGTH;
        }

从getSpillIndexFileForWrite方法来看，其命名是output/spill2.out.index等等：

  public Path getSpillIndexFileForWrite(int spillNumber, long size)
      throws IOException {
    return lDirAlloc.getLocalPathForWrite(TaskTracker.OUTPUT + "/spill"
        + spillNumber + ".out.index", size, conf);
  }

所以，实际上并不是一个Spill文件就对应于一个spill index文件。但一个Spill文件确实是对应于一个SpillRecord的，一个SpillRecord的大小等于分区数量*24字节。

17，到此为止，MapOutputBuffer的基本处理过程就明白了，那么，什么时候结束呢，自然是当Map输入数据处理完毕之后，由下面的代码进行结束的：

    try {
      runner.run(in, new OldOutputCollector(collector, conf), reporter);
      collector.flush();

      in.close();
      in = null;
      collector.close();
      collector = null;
    } finally {
      closeQuietly(in);
      closeQuietly(collector);
    }

此时就调用了collector的flush方法。在map内只是调用其collect方法。因此我们再来看看其flush方法。

flush方法的逻辑还是比较清楚的，首先对kvbuffer内剩余还没有Spill的数据进行Spill：

      spillLock.lock();
      try {
        while (kvstart != kvend) {
          reporter.progress();
          spillDone.await();
        }
        if (sortSpillException != null) {
          throw (IOException)new IOException("Spill failed"
              ).initCause(sortSpillException);
        }
        if (kvend != kvindex) {
          kvend = kvindex;
          bufend = bufmark;
          sortAndSpill();
        }
      } catch (InterruptedException e) {
        throw (IOException)new IOException(
            "Buffer interrupted while waiting for the writer"
            ).initCause(e);
      } finally {
        spillLock.unlock();
      }

可以看出，此时是这个线程调用了sortAndSpill方法（之前是SpillThread那个线程调用）。

全部刷写到磁盘后，给SpillThread线程发送暂停信号，等待SpillThread关闭（join方法）：

      try {
        spillThread.interrupt();
        spillThread.join();
      } catch (InterruptedException e) {
        throw (IOException)new IOException("Spill failed"
            ).initCause(e);
      }

之后，我们得到了N个Spill文件以及多个索引文件，于是需要按照分区归并成分区数量个文件，调用mergeParts方法。mergeParts方法的目的是将多个Spill文件合并为一个，注意，虽然最后要把结果送到多个Reduce任务去，但仍然只是写到一个文件里，不同Reduce任务需要的数据在文件的不同区域。按照SpillRecord索引信息可以取出来。

18，在mergeParts里，首先获得这些Spill文件的文件名：

      for(int i = 0; i < numSpills; i++) {
        filename[i] = mapOutputFile.getSpillFile(i);
        finalOutFileSize += rfs.getFileStatus(filename[i]).getLen();
      }

如果numSpills=1，那么Spill文件相当于就是要Map输出的文件，因为在Spill内部已经进行了排序。而且因为没有多余的Spill文件需要归并，所以重命名文件名即可：

      if (numSpills == 1) { //the spill is the final output
        rfs.rename(filename[0], new Path(filename[0].getParent(), "file.out"));
        if (indexCacheList.size() == 0) {
          rfs.rename(mapOutputFile.getSpillIndexFile(0),
              new Path(filename[0].getParent(),"file.out.index"));
        } else {
          indexCacheList.get(0).writeToFile(new Path(filename[0].getParent(),"file.out.index"), job);
        }
        return;
      }

此时，Map输出文件名为output/file.out和output/file.out.index。

如果多于一个Spill文件，则需要进行归并处理。

首先将全部索引数据从文件中读出来，加入到indexCacheList数组里，这里似乎有一个问题，如果索引文件太大怎么办，会不会导致Out of Memory？不过粗略算一下应该不太可能，假定Reduce个数是100个，一个SpillRecord的大小则是2400字节。假定Map任务输出100个Spill文件，则indexCacheList大小为240000字节，240KB。这个数量级已经是MapReduce中比较大的了，所以可以忽略这个问题。

      // read in paged indices
      for (int i = indexCacheList.size(); i < numSpills; ++i) {
        Path indexFileName = mapOutputFile.getSpillIndexFile(i);
        indexCacheList.add(new SpillRecord(indexFileName, job, null));
      }

获得这个indexCacheList的目的是为了方便地找到某个分区在各个Spill文件中的位置，以便进行归并处理：

之后，获得最终要输出的文件名：

      //make correction in the length to include the sequence file header
      //lengths for each partition
      finalOutFileSize += partitions * APPROX_HEADER_LENGTH;
      finalIndexFileSize = partitions * MAP_OUTPUT_INDEX_RECORD_LENGTH;
      Path finalOutputFile = mapOutputFile.getOutputFileForWrite(finalOutFileSize);
      Path finalIndexFile = mapOutputFile.getOutputIndexFileForWrite(finalIndexFileSize);

从下面可以看出Map输出的文件名，分别是file.out和file.out.index，最终输出也就是这两个文件：

  public Path getOutputFileForWrite(long size)
      throws IOException {
    return lDirAlloc.getLocalPathForWrite(TaskTracker.OUTPUT + Path.SEPARATOR
        + "file.out", size, conf);
  }

  public Path getOutputIndexFileForWrite(long size)
      throws IOException {
    return lDirAlloc.getLocalPathForWrite(TaskTracker.OUTPUT + Path.SEPARATOR
        + "file.out.index", size, conf);
  }

创建文件，rfs是本地文件系统：

      //The output stream for the final single output file
      FSDataOutputStream finalOut = rfs.create(finalOutputFile, true, 4096);

如果一个分区文件都没有，也需要创建记录文件（CRC等信息，这样更不会出错，否则会不会文件被删了？）：

      if (numSpills == 0) {
        //create dummy files
        IndexRecord rec = new IndexRecord();
        SpillRecord sr = new SpillRecord(partitions);
        try {
          for (int i = 0; i < partitions; i++) {
            long segmentStart = finalOut.getPos();
            Writer<K, V> writer = new Writer<K, V>(job, finalOut, keyClass, valClass, codec, null);
            writer.close();
            rec.startOffset = segmentStart;
            rec.rawLength = writer.getRawLength();
            rec.partLength = writer.getCompressedLength();
            sr.putIndex(rec, i);
          }
          sr.writeToFile(finalIndexFile, job);
        } finally {
          finalOut.close();
        }
        return;
      }

否则，对于每个分区进行一个大循环，内部对每个Spill文件进行一个小循环：

        for (int parts = 0; parts < partitions; parts++) {
          List<Segment<K,V>> segmentList =
            new ArrayList<Segment<K, V>>(numSpills);
          for(int i = 0; i < numSpills; i++) {
            IndexRecord indexRecord = indexCacheList.get(i).getIndex(parts);

            Segment<K,V> s =
              new Segment<K,V>(job, rfs, filename[i], indexRecord.startOffset,
                               indexRecord.partLength, codec, true);
            segmentList.add(i, s);
。。。。。。。

segmentList是关于一个分区的信息，这个分区信息在每一个Spill文件中都存在，根据IndexRecord可以生成出来，除了位置信息，还包括是否采用了压缩等等信息。

之后，调用Merger中的merge方法进行归并处理：

          //merge
          @SuppressWarnings("unchecked")
          RawKeyValueIterator kvIter = Merger.merge(job, rfs,
                         keyClass, valClass, codec,
                         segmentList, job.getInt("io.sort.factor", 100),
                         new Path(mapId.toString()),
                         job.getOutputKeyComparator(), reporter,
                         null, spilledRecordsCounter);

这个方法也比较复杂，主要实现的是归并排序，在后面各节再进行详细分析。这里可以看出，在一个Map任务内，对于某个分区的那些记录，默认用快速排序（QuickSort）实现，之后更大范围的排序使用归并排序。

归并完毕后，将其写入文件，这里又见到了Combine，我们在前面已经分析过Combine，那里是对每个刷写Spill文件之前某个分区的KV进行合并，这里是对归并排序后每个分区的结果进行归并，是不是冗余了？实际上不是，前面那个Combine还是局部的Combine，后面这个Combine是在前面的那个合并的基础上进行的再次合并。比如要对64MB的文本计算hello这个单词出现的次数，前面那个Combine比如是对每1MB内的文本累积次数，一共有64个数，最后这个Combine是对64个数加起来，得到64MB中hello的次数，这就是Map的输出结果；Reduce那边则是对整个大文件（比如6400MB）的hello次数根据不同Map任务（即100个数）输出的结果进行再次累和，Combine基本上可以理解为就是Map端的Reduce。因此，从Combine、Sort等过程来看，MapReduce就是一个将小数据的结果进行处理，得到局部（合并、排序）结果后，然后不断汇总处理的过程。基本上有三个阶段，一个是在单个Spill内，一个是单个Map内，一个是全局处理。个人理解这算是MapReduce的核心思想。

          Writer<K, V> writer =
              new Writer<K, V>(job, finalOut, keyClass, valClass, codec,
                               spilledRecordsCounter);
          if (combinerRunner == null || numSpills < minSpillsForCombine) {
            Merger.writeFile(kvIter, writer, reporter, job);
          } else {
            combineCollector.setWriter(writer);
            combinerRunner.combine(kvIter, combineCollector);
          }

同样，对每个分区都记录索引信息：

          // record offsets
          rec.startOffset = segmentStart;
          rec.rawLength = writer.getRawLength();
          rec.partLength = writer.getCompressedLength();
          spillRec.putIndex(rec, parts);

等到每个分区都完成了上面的步骤后，将索引信息写入到一个文件：

spillRec.writeToFile(finalIndexFile, job);

然后删除以前写入的各个Spill文件：

        for(int i = 0; i < numSpills; i++) {
          rfs.delete(filename[i],true);
        }

于是整个Map输出过程即结束。

后记：本节将Map处理后的结果（Key-Value记录序列）如何处理的过程分析了一遍，其核心思想是要按照分区来处理，以便送到不同的Reduce任务，先缓存、到达一定程度后刷写磁盘，刷写之前进行Spill这个层面的Combine和Sort，得到N个Spill文件，最后，对N个Spill文件的结果进行归并排序和二次Combine。最终得到一个结果文件写入到本地，等待Reduce来取，至于Reduce怎么来取，以及Map端又怎么配合，在后续博文中再进行分析。

另外，从本节可以看出，一个好的框架不仅仅是思想，更重要的是为了实现这些想法，采用哪些算法和数据结构，比如缓存怎么设计，排序如何实现，使得流程既高效，又通用，这可能就是软件框架设计的核心吧。慢慢学习。