HDFS源码分析之LightWeightGSet

LightWeightGSet是名字节点NameNode在内存中存储全部数据块信息的类BlocksMap需要的一个重要数据结构，它是一个占用较低内存的集合的实现，它使用一个数组array存储元素，使用linked lists来解决冲突。它没有实现重新哈希分区，所以，内部的array不会改变大小。这个类不支持null元素，并且不是线程安全的。它在BlocksMap中的初始化如下：

 

this.blocks = new LightWeightGSet<Block, BlockInfo>(capacity)// ...省略部分代码

 

        可见，它类似一个Key、Value集合，Key为BLock对象，Value为BlockInfo对象。

        那么，对于LightWeightGSet的上述介绍该如何解释呢？既然看上去像一个Key、Value集合，那么它到底是不是一个Key、Value集合呢？而且，为什么说它占内存比较低，使用数组存储元素，又用linked lists来解决冲突呢？相信当你看完LightWeightGSet的实现，就会一目了然。我们先看下LightWeightGSet中最重要的一个成员变量，如下：

 

/**
 * An internal array of entries, which are the rows of the hash table.
 * The size must be a power of two.
 * 存储元素条目的内部数组，它是哈希表中的行。
 * 数组大小必须是2的幂。
 * 数组元素实现了LinkedElement接口。
 */
private final LinkedElement[] entries;

        entries是一个存储实现了LinkedElement接口对象的数组，实际上存储的是BlockInfo实例。它是LightWeightGSet存储元素条目的内部数组，数组中元素是哈希表中的一行，且数组的大小必须为2的幂。

        先了解上述信息就行，我们再往下看，既然是一个集合，就得能够实现存取元素，LightWeightGSet肯定得对外提供了元素存取的方法，先看存，通过put()方法实现，代码如下：

 

 @Override
 public E put(final E element) {
   //validate element
// 检验元素element

// 不支持null元素
   if (element == null) {
     throw new NullPointerException("Null element is not supported.");
   }

   // 元素必须实现LinkedElement接口
   if (!(element instanceof LinkedElement)) {
     throw new HadoopIllegalArgumentException(
         "!(element instanceof LinkedElement), element.getClass()="
         + element.getClass());
   }

   // 将元素element强制转换成LinkedElement类型实例e
   final LinkedElement e = (LinkedElement)element;

   //find index
   // 获取元素对应索引
   // 实际上是根据block的hashCode和hash_mask的一种循环取余算法
   // blockID是一个递增的序列，它在数组内的index也是在数组长度范围内递增的
   final int index = getIndex(element);

   //remove if it already exists
   // 如果元素已经存在的话，移除
   final E existing = remove(index, element);

   //insert the element to the head of the linked list
   // 将元素element插入到linked列表的头部

   // 累加modification、size
   modification++;
   size++;

   // 元素设置
   // 将e的next元素设置为数组当前index位置的元素
   e.setNext(entries[index]);
   // 将e的next元素设置为数组当前index位置的元素
   entries[index] = e;

   // 返回之前存储的元素existing
   return existing;
 }

        put()方法实现了LightWeightGSet存数据的功能，它接收一个E泛型element作为参数，实现逻辑如下：

 

        1、首先校验参数，即需要存储的元素element，它必须满足不能为null和必须实现LinkedElement接口两个限制条件；

        2、然后将元素element强制转换成LinkedElement类型实例e；

        3、调用getIndex()方法根据元素element获取它在数组entries中对应的位置索引index；

        4、如果元素存在的话，调用remove()方法，根据位置索引index和元素remove进行移除操作，并得到有可能之前存储的元素existing；

        5、累加modification、size：

              modification代表了数据修改量，无论增加还是删除，均会累加；

              size代表了集合元素个数，增加元素时即累加，删除元素时即累减；

        6、进行元素设置：

              6.1、将e的next元素设置为数组当前index位置的元素，可能为null，也可能为之前存在的不等元素，但肯定不是和需要添加元素相等的元素，因为如果存在，上面就已经删除了；

              6.2、将当前元素e设置为数组当前index位置的元素；

        7、将当前元素e设置为数组当前index位置的元素。
        通过上述添加元素过程的逻辑介绍，你是不是能体会到以下这点呢：

        LightWeightGSet在内存中本质上是一个数组entries，用于存储实现了LinkedElement接口的元素。当添加元素element时，我们能够根据待添加元素element计算出它在数组entries中的位置索引index，然后根据位置索引index和元素element删除之前可能存在的相等元素，然后再进行元素设置，将数组entries中当前位置索引index处的元素设置为待添加元素element的next元素，而将待添加元素element放置到数组entries中的位置索引index处。

        看到这里，你是不是恍然大悟，是不是能感受到LightWeightGSet中的数组中每个位置存储的好像是一个列表，而不是单一的一个元素？如果你能体会到这点，你就能开始领会到LightWeightGSet的真谛了。而且，我们已经能够开始回答上面我们遗留的使用一个数组array存储元素，使用linked lists来解决冲突这个疑问了。

        待会总结，继续往下看。

        我们来看看上述put过程中，如何通过getIndex()方法根据元素element获取它在数组entries中对应的位置索引index，代码如下：

 

private int getIndex(final K key) {
  return key.hashCode() & hash_mask;
}

        我们知道，LightWeightGSet中存储的元素都是实现了LightWeightGSet.LinkedElement接口的对象，实际上也就是BlockInfo对象（别问我怎么知道的是BlockInfo，你去看看BlocksMap中对LightWeightGSet实例的应用你也能知道），而这个getIndex()方法的入参正式集合元素BlockInfo对象，我们看下BlockInfo的hashCode()方法，代码如下：

 

 

@Override
public int hashCode() {
  // Super implementation is sufficient
  return super.hashCode();
}

        直接调用父类的hashCode()方法，也就是Block的hashCode()方法，代码如下：

 

 

@Override // Object
public int hashCode() {
  //GenerationStamp is IRRELEVANT and should not be used here
  return (int)(blockId^(blockId>>>32));
}

        很简单，对于其long类型成员变量blockId的位操作而已，那么这个blockId一般都是什么呢？其实就是一个long类型的起始自1024L * 1024 * 1024 + 1的递增数字而已，具体介绍请参考《HDFS源码分析blockId生成分析》一文。

 

        针对上述getIndex()方法，我们做个简单的测试，代码如下：

 

@Test
public void testGetIndexAndPrint(){

    // 起始数据块ID
    long LAST_RESERVED_BLOCK_ID = 1024L * 1024 * 1024 + 1;

    // 运算因子
    // 至于运算因子为什么选用1023，我们后续介绍，这里你只要知道它是数组长度减一就行
    int hash_mask = 1023;

    // 循环递增生成blockId（供生成1024+100个），并利用getIndex()方法的等价运算逻辑进行运算
    for (long blockId = LAST_RESERVED_BLOCK_ID; blockId < LAST_RESERVED_BLOCK_ID + 1024 + 100; blockId++) {

        // 计算hashCode
        int hashCode = (int) (blockId ^ (blockId >>> 32));

        // 计算index
        int index = hashCode & hash_mask;
        System.out.println("blockId=" + blockId + ";hashCode=" + hashCode
                + ";hash_mask=" + hash_mask + ";index=" + index);
    }

}

        这里，首先需要说明一点，至于运算因子为什么选用1023，我们后续介绍，这里你只要知道它是LightWeightGSet中数组entries长度减一就行。我们看下运行结果：

 

 

blockId=1073741825;hashCode=1073741825;hash_mask=1023;index=1
blockId=1073741826;hashCode=1073741826;hash_mask=1023;index=2
blockId=1073741827;hashCode=1073741827;hash_mask=1023;index=3
blockId=1073741828;hashCode=1073741828;hash_mask=1023;index=4
blockId=1073741829;hashCode=1073741829;hash_mask=1023;index=5
blockId=1073741830;hashCode=1073741830;hash_mask=1023;index=6
blockId=1073741831;hashCode=1073741831;hash_mask=1023;index=7
blockId=1073741832;hashCode=1073741832;hash_mask=1023;index=8
blockId=1073741833;hashCode=1073741833;hash_mask=1023;index=9
blockId=1073741834;hashCode=1073741834;hash_mask=1023;index=10
blockId=1073741835;hashCode=1073741835;hash_mask=1023;index=11

...
省略中间连续输出结果
...

blockId=1073742844;hashCode=1073742844;hash_mask=1023;index=1020
blockId=1073742845;hashCode=1073742845;hash_mask=1023;index=1021
blockId=1073742846;hashCode=1073742846;hash_mask=1023;index=1022
blockId=1073742847;hashCode=1073742847;hash_mask=1023;index=1023
blockId=1073742848;hashCode=1073742848;hash_mask=1023;index=0
blockId=1073742849;hashCode=1073742849;hash_mask=1023;index=1
blockId=1073742850;hashCode=1073742850;hash_mask=1023;index=2
blockId=1073742851;hashCode=1073742851;hash_mask=1023;index=3
blockId=1073742852;hashCode=1073742852;hash_mask=1023;index=4
blockId=1073742853;hashCode=1073742853;hash_mask=1023;index=5

...
省略中间连续输出结果
...

blockId=1073742942;hashCode=1073742942;hash_mask=1023;index=94
blockId=1073742943;hashCode=1073742943;hash_mask=1023;index=95
blockId=1073742944;hashCode=1073742944;hash_mask=1023;index=96
blockId=1073742945;hashCode=1073742945;hash_mask=1023;index=97
blockId=1073742946;hashCode=1073742946;hash_mask=1023;index=98
blockId=1073742947;hashCode=1073742947;hash_mask=1023;index=99
blockId=1073742948;hashCode=1073742948;hash_mask=1023;index=100

        可以看到，如果递增的数据块ID在数组内的位置索引index是从头至尾递增并循环的，这类似于循环取余操作。所以，数组内每个位置的元素肯定不止一个，而且，理论上是完全完整的连续存储的，仅仅是理论上哦，毕竟数据块申请后有可能放弃或者损坏的数据块被检测，导致实际的存储并不完全完整的连续。

 

        到了这里，你应该对LightWeightGSet的存储有了更深一步的了解了吧！

        下面，我们再看下添加元素时需要用到的重复元素删除remove()方法，它返回被删除的元素，没有元素可删除则返回null，代码如下：

 

 /**
  * Remove the element corresponding to the key,
  * given key.hashCode() == index.
  *
  * @return If such element exists, return it.
  *         Otherwise, return null.
  */
 private E remove(final int index, final K key) {

// 如果entries数组index处的元素为null，直接返回null
if (entries[index] == null) {
     return null;
   } else if (entries[index].equals(key)) {
     // 如果entries数组index处的元素等于key

     //remove the head of the linked list
     // modification累加
     modification++;

     // 元素个数减一
     size--;

     // 取出entries数组index处的元素e
     final LinkedElement e = entries[index];

     // 将entries数组index处的元素替换为e的next元素
     entries[index] = e.getNext();

     // e的next元素设置为null
     e.setNext(null);

     // 将e转换下并返回
     return convert(e);
   } else {
     //head != null and key is not equal to head
     //search the element
     // 如果列表头部head不为null，且不等于需要删除的key

     // 遍历列表元素，直到找到需要删除的key或者遍历完列表全部元素

     // 取出列表头部元素prev
     LinkedElement prev = entries[index];

     // 遍历prev的后续元素curr
     for(LinkedElement curr = prev.getNext(); curr != null; ) {
       if (curr.equals(key)) {// 如果curr等于key，说明我们已经找到元素，移除它

         //found the element, remove it
         // 修改数目累加
         modification++;
         // 元素个数累减
         size--;
         // 上一个元素prev的next指向当前元素curr的next，即砍掉当前元素
         prev.setNext(curr.getNext());
         // 当前元素curr的next设置为null
         curr.setNext(null);
         // 将当前元素curr转换并返回
         return convert(curr);
       } else {
         // 没找到的话，上一个元素prev赋值为当前元素curr，当前元素curr取下一个元素next
         prev = curr;
         curr = curr.getNext();
       }
     }

     //element not found
     // 都没找到的话返回null
     return null;
   }
 }

        了解了上面的put过程，及LightWeightGSet的存储原理，相信你应该能看懂remove()方法的逻辑。为了加深理解，我们这里再简单概括下，它分123三种情况，大体逻辑如下：

 

        1、如果entries数组index处的元素为null，直接返回null；

        2、如果entries数组index处的元素等于key，即待添加或者其他的指定元素，则：

              2.1、修改量modification累加，元素个数size累减；

              2.2、取出entries数组index处的元素e；

              2.3、将entries数组index处的元素替换为e的next元素；

              2.4、e的next元素设置为null；

              2.5、将e转换下并返回；

        3、如果entries数组index处的元素不等于key，即待添加或者其他的指定元素，则遍历列表元素，直到找到需要删除的key或者遍历完列表全部元素：

              3.1、取出列表头部元素prev；

              3.2、遍历prev的后续元素curr：

                       3.2.1、如果curr等于key，说明我们已经找到元素，移除它：

                                    3.2.1.1、修改量modification累加，元素个数size累减；

                                    3.2.1.2、上一个元素prev的next指向当前元素curr的next，即砍掉当前元素；

                                    3.2.1.3、当前元素curr的next设置为null；

                                    3.2.1.4、将当前元素curr转换并返回；

                       3.2.2、没找到的话，上一个元素prev赋值为当前元素curr，当前元素curr取下一个元素next；

        4、都没找到的话返回null。
        上面，元素的添加、移除都讲到了，下面我们看下元素的获取get()方法，代码如下：

 

@Override
public E get(final K key) {
  //validate key
/ 校验key：key不能为null
  if (key == null) {
    throw new NullPointerException("key == null");
  }

  //find element
  // 寻找元素

  // 根据key，获取索引index
  final int index = getIndex(key);

  // 取出数组entries中index位置的元素，当e不为null时，判断e是否等于key，如果相等，convert转换下，如果不相等，通过循环e的getNext()遍历后续元素，重复上述判断
  for(LinkedElement e = entries[index]; e != null; e = e.getNext()) {
    if (e.equals(key)) {
      return convert(e);
    }
  }

  //element not found
  // 没有找到元素的话，返回null
  return null;
}

        十分简单，具体如下：

 

        1、先校验key：key不能为null；

        2、根据key，获取索引index；

        3、取出数组entries中index位置的元素，当e不为null时，判断e是否等于key，如果相等，convert转换下，如果不相等，通过循环e的getNext()遍历后续元素，重复上述判断；

        4、没有找到元素的话，返回null。

 

        既然LightWeightGSet本质上是一个数组，那么数组在内存中应该是固定大小的，这个固定的大小是如何确定的呢？我们先看下LightWeightGSet的构造方法，如下：

 

 /**
  * @param recommended_length Recommended size of the internal array.
  */
 public LightWeightGSet(final int recommended_length) {

// 根据推荐数组长度recommended_length计算实际数组长度actual
   final int actual = actualArrayLength(recommended_length);
   if (LOG.isDebugEnabled()) {
     LOG.debug("recommended=" + recommended_length + ", actual=" + actual);
   }

   // 初始化entries为指定大小actual的LinkedElement数组
   entries = new LinkedElement[actual];

   // hash_mask默认为entries数组大小减1
   hash_mask = entries.length - 1;
 }

        构造方法需要一个参数recommended_length，即推荐的数组长度，并且，我们需要根据根据推荐数组长度recommended_length计算实际数组长度actual，然后初始化entries为指定大小actual的LinkedElement数组，而hash_mask默认为entries数组大小减1，至于为什么这么做，相信看过上面的介绍你应该能找到答案吧！

 

        我们看下actualArrayLength()方法，代码如下：

 

//compute actual length
// 根据推荐长度recommended和最大最小阈值计算实际长度actual
private static int actualArrayLength(int recommended) {

f (recommended > MAX_ARRAY_LENGTH) {// 如果推荐长度recommended超过最大长度，则实际长度actual取值最大长度
    return MAX_ARRAY_LENGTH;
  } else if (recommended < MIN_ARRAY_LENGTH) {// 如果推荐长度recommended低于最小长度，则实际长度actual取值最小长度
    return MIN_ARRAY_LENGTH;
  } else {

    // 推荐长度在最大最小阈值范围内的话，返回大于等于recommended的最近的2的n次幂
    // 确保数组长度为2的n次幂
    final int a = Integer.highestOneBit(recommended);
    return a == recommended? a: a << 1;
  }
}

        实际上很简单，确保数组真实长度在阈值上限MAX_ARRAY_LENGTH和下限MIN_ARRAY_LENGTH之前，并且推荐长度在最大最小阈值范围内的话，返回大于等于recommended的最近的2的n次幂，确保数组长度为2的n次幂。

 

        这个数组长度阈值上下限的定义如下：

 

// array最大大小为2的30次方，即1073741824
static final int MAX_ARRAY_LENGTH = 1 << 30; //prevent int overflow problem

// array最小大小为1
static final int MIN_ARRAY_LENGTH = 1;

        那么，构造LightWeightGSet时，这个推荐长度如何定义呢？这个需要看下BlockManager中对blocksMap的初始化，如下：

 

 

// Compute the map capacity by allocating 2% of total memory
blocksMap = new BlocksMap(
    LightWeightGSet.computeCapacity(2.0, "BlocksMap"));

        它是通过总内存大小的2%来分配的，调用了LightWeightGSet的computeCapacity()方法来计算，代码如下：

 

 

/**
 * Let t = percentage of max memory.
 * Let e = round(log_2 t).
 * Then, we choose capacity = 2^e/(size of reference),
 * unless it is outside the close interval [1, 2^30].
 */
public static int computeCapacity(double percentage, String mapName) {
  return computeCapacity(Runtime.getRuntime().maxMemory(), percentage,
      mapName);
}

        通过Runtime.getRuntime().maxMemory()获取总内存大小，然后传入百分比percentage和使用这些内存的map名称mapName，调用三个参数的computeCapacity()方法，如下：

 

 

@VisibleForTesting
static int computeCapacity(long maxMemory, double percentage,
    String mapName) {

/ 校验内存百分比percentage的合法性，必须在[0-1]之间
  if (percentage > 100.0 || percentage < 0.0) {
    throw new HadoopIllegalArgumentException("Percentage " + percentage
        + " must be greater than or equal to 0 "
        + " and less than or equal to 100");
  }

  // 校验总内存大小maxMemory的合法性，必须大于等于0
  if (maxMemory < 0) {
    throw new HadoopIllegalArgumentException("Memory " + maxMemory
        + " must be greater than or equal to 0");
  }

  // 如果内存百分比percentage、总内存大小maxMemory其中任一为0，直接返回0
  if (percentage == 0.0 || maxMemory == 0) {
    return 0;
  }

  //VM detection
  //See http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_detection
  // 机器是否为32位
  final String vmBit = System.getProperty("sun.arch.data.model");

  //Percentage of max memory

  // 百分比因子percentDivisor
  final double percentDivisor = 100.0/percentage;

  // 需要使用的内存percentMemory，实际上就是maxMemory*percentage/100
  final double percentMemory = maxMemory/percentDivisor;

  //compute capacity
  // 计算容量
  final int e1 = (int)(Math.log(percentMemory)/Math.log(2.0) + 0.5);
  final int e2 = e1 - ("32".equals(vmBit)? 2: 3);
  final int exponent = e2 < 0? 0: e2 > 30? 30: e2;
  final int c = 1 << exponent;

  LOG.info("Computing capacity for map " + mapName);
  LOG.info("VM type       = " + vmBit + "-bit");
  LOG.info(percentage + "% max memory "
      + StringUtils.TraditionalBinaryPrefix.long2String(maxMemory, "B", 1)
      + " = "
      + StringUtils.TraditionalBinaryPrefix.long2String((long) percentMemory,
          "B", 1));
  LOG.info("capacity      = 2^" + exponent + " = " + c + " entries");
  return c;
}

 

        方法很简单，读者可自行分析。

        

        我们回到最初关于LightWeightGSet的一些介绍，它是一个占用较低内存的集合的实现，使用一个数组array存储元素，使用linked lists来解决冲突。它没有实现重新哈希分区，所以，内部的array不会改变大小。这个类不支持null元素，并且不是线程安全的。

        现在再来看上面这段话，怎么解释它们，相信你心中应该有些答案了吧！这里，我们还是一起来分析下：

        首先，我们要知道数组和链表的异同及各自的优缺点，如下：

        从逻辑结构来看

        1、数组必须事先确定固定长度，它不能适应数据动态增减情况的变化，即不能存储超过固定长度的元素，如果存储的元素没有达到固定长度，又会造成资源的浪费，但是数组可以根据下标直接存取；

        2、链表动态地进行存储分配，可以适应数据动态地增减的情况，且可以方便地插入、删除数据项。它必须通过next指针找到下一个元素。

        从内存存储来看

        1. （静态）数组从栈中分配空间, 对于程序员方便快速,但是自由度小；

        2、链表从堆中分配空间, 自由度大但是申请管理比较麻烦。

        从上面的比较可以看出，如果需要快速访问数据，很少或不插入和删除元素，就应该用数组；相反， 如果需要经常插入和删除元素就需要用链表数据结构了。

 

        那么LightWeightGSet使用它这种数据加链表的存储结构，有什么好处呢？

        首先，使用数组，可以很方便的申请内存，且占用内存比较低，考虑了初始内存使用的感受，检索比较快；

        其次，使用链表，可以适应数据动态增减的变化，但是检索性能肯定不如数组；

        然后，将二者融合，即照顾了内存申请等的物理需要，又考虑到了数据动态增减的逻辑业务需要；

        最后，先定位数组索引，再遍历链表元素，可以大大改善只使用链表数据检索的性能；

        综上，LightWeightGSet是一种将数组、链表融合的非常好的折中方案，很值得我们以后在自己的系统内学习借鉴。

        总结：

        LightWeightGSet是名字节点NameNode在内存中存储全部数据块信息的类BlocksMap需要的一个重要数据结构，它是一个占用较低内存的集合的实现，它使用一个数组存储元素，数组中存储的元素实际上是一个链表，这样，综合利用了数组、链表各自在内存申请、动态扩展、检索等方面的优势，取长补短、相互促进。它利用long类型的blockId，采用一定的高效的哈希映射算法来定位元素在数组中的位置，并将其添加到列表头部，删除与查询亦是类似定位过程，先确定数组位置，然后遍历列表，做查询或删除操作。