摘要：公司使用來作為通訊格式，一個同事這樣的寫法文件格式使用的時候這時候拿到的是一個要是改成這樣這時候拿到的是一個為什么會出現(xiàn)這種情況呢讀了源碼才知道是這樣處理的這里發(fā)現(xiàn)只要才會進行包裝，要不調(diào)用的是那么是什么時候變成不為呢繼續(xù)看代碼發(fā)現(xiàn)只要是調(diào)

公司使用protobuf來作為通訊格式，一個同事這樣的寫法
proto文件格式：

message PlayerFightQueue {
    optional  int32      fightQueueId            = 1;
    repeated  CurArmy     curArmy                = 2;
}

使用的時候：

PlayerFightQueue.Builder fightQueue= getPlayerFightQueue();
List armies = fightQueue.getCurArmyList();



這時候armies拿到的是一個java.util.Collections.unmodifiableList

要是改成這樣：

PlayerFightQueue.Builder fightQueue= getPlayerFightQueue();
fightQueue.getCurArmyBuilderList();
List armies = fightQueue.getCurArmyList();

這時候armies拿到的是一個RepeatedFieldBuilder.list

為什么會出現(xiàn)這種情況呢？
讀了源碼才知道protobuf是這樣處理的：

  public java.util.List getCurArmyList() {
    if (curArmyBuilder_ == null) {
      return java.util.Collections.unmodifiableList(curArmy_);
    } else {
      return curArmyBuilder_.getMessageList();
    }
  }

這里發(fā)現(xiàn)只要curArmyBuilder_ == null才會進行包裝，要不調(diào)用的是curArmyBuilder_.getMessageList()
那么curArmyBuilder_ 是什么時候變成不為null呢？
繼續(xù)看代碼：

 public java.util.List 
       getCurArmyBuilderList() {
    return getCurArmyFieldBuilder().getBuilderList();
  }
  private com.google.protobuf.RepeatedFieldBuilder<
      com.wl.protocol.rpc.msg.CurArmyMsg.CurArmy, com.wl.protocol.rpc.msg.CurArmyMsg.CurArmy.Builder, com.wl.protocol.rpc.msg.CurArmyMsg.CurArmyOrBuilder> 
      getCurArmyFieldBuilder() {
    if (curArmyBuilder_ == null) {
      curArmyBuilder_ = new com.google.protobuf.RepeatedFieldBuilder<
          com.wl.protocol.rpc.msg.CurArmyMsg.CurArmy, com.wl.protocol.rpc.msg.CurArmyMsg.CurArmy.Builder, com.wl.protocol.rpc.msg.CurArmyMsg.CurArmyOrBuilder>(
              curArmy_,
              ((bitField0_ & 0x00000080) == 0x00000080),
              getParentForChildren(),
              isClean());
      curArmy_ = null;
    }
    return curArmyBuilder_;
  }

發(fā)現(xiàn)只要是調(diào)用了builder方法會改變curArmyBuilder_ 而curArmy_就會被變成null

遇到這種情況還是不要偷懶，老老實實的深復制吧，也許就會出現(xiàn)埋點很深的坑