如何修复RecyclerView中的IndexOutOfBoundsException异常

这个Inconsistency detected的异常我在项目里碰到过好几次，本质就是RecyclerView的内部状态和你的数据源对不上了——看堆栈里的state:11，说明RecyclerView认为当前列表有11个item，但实际你的数据源里的数量已经少于这个数，当它尝试访问第8个item时就触发了崩溃。结合你的场景，我给你梳理几个排查和修复的方向：

一、先盯紧数据源的线程安全 #

这是最常见的触发原因：

• 所有修改聊天列表数据源的操作（添加、删除、清空消息），必须在主线程执行。RecyclerView的UI更新和数据源强绑定，后台线程直接改数据源会导致数据和UI状态异步，很容易出现这种不一致。
• 如果有后台任务需要更新数据，一定要通过runOnUiThread、Handler或者Coroutines的Dispatchers.Main切换到主线程再修改，或者用线程安全的集合（比如CopyOnWriteArrayList）来存储数据。

二、检查Adapter的notify调用是否规范 #

看你的Adapter逻辑，大概率是notify方法用得不对：

• 别一修改数据就直接调用notifyDataSetChanged()，这个方法会强制RecyclerView全量刷新，很容易掩盖状态不一致的问题，而且效率低。应该用更精确的方法：notifyItemInserted()、notifyItemRemoved()、notifyItemRangeChanged()，这些方法会让RecyclerView正确更新内部的item计数和位置映射。
• 绝对不要在修改数据源和调用notify之间插入耗时操作——比如修改列表后先去请求网络再notify，这期间RecyclerView的预加载机制（就是堆栈里的GapWorker，负责提前加载屏幕外的item）可能已经开始工作，导致它访问了已经不存在的位置。
• 核对getItemCount()的返回值：确保它返回的是数据源的实时大小，比如不要在方法里硬写固定值，或者缓存了旧的数量。

三、针对GapWorker的特殊排查 #

堆栈里的异常出在GapWorker相关方法，这是RecyclerView的预加载组件。可能的场景是：

• 当RecyclerView正在预加载屏幕外的item时，数据源突然被修改，导致预加载的位置超出了新的数据源长度。
• 你可以先试试关闭预加载来验证：给你的LinearLayoutManager设置setItemPrefetchEnabled(false)，如果异常消失，说明问题出在预加载和数据更新的冲突上。这种情况下，你可以在更新数据前先调用recyclerView.stopScroll()，让RecyclerView停止滚动和预加载，再修改数据并notify。

四、实用的调试技巧 #

• 给数据源的所有修改操作加日志，记录修改前后的数量和当前线程：

  int oldSize = mChatList.size();
  // 你的修改逻辑
  int newSize = mChatList.size();
  Log.d("ChatListDebug", "修改数据源 | 线程：" + Thread.currentThread().getName() + " | 旧数量：" + oldSize + " | 新数量：" + newSize);
  

• 在Adapter的getItemCount()里加日志，看看RecyclerView请求数量时的数值和实际数据源是否匹配：

  @Override
  public int getItemCount() {
      int count = mChatList.size();
      Log.d("ChatListDebug", "RecyclerView请求item数量：" + count);
      return count;
  }
  

• 给onBindViewHolder加个try-catch，捕获异常时打印当前的位置和数据源大小，方便定位：

  @Override
  public void onBindViewHolder(ViewHolder holder, int position) {
      try {
          // 原来的绑定逻辑
      } catch (IndexOutOfBoundsException e) {
          Log.e("ChatListDebug", "绑定异常 | 位置：" + position + " | 数据源大小：" + mChatList.size(), e);
          // 这里可以做容错，比如给holder设置空内容
      }
  }
  

五、紧急上线的临时修复 #

如果暂时找不到根因，先加个临时容错避免崩溃：

// 给RecyclerView设置全局的异常拦截
recyclerView.setRecyclerListener(new RecyclerView.RecyclerListener() {
    @Override
    public void onViewRecycled(RecyclerView.ViewHolder holder) {
        // 空实现即可，主要是让RecyclerView在回收view时更稳定
    }
});

// 或者包装你的Adapter，做安全校验
public class SafeChatAdapter extends YourChatAdapter {
    @Override
    public int getItemCount() {
        return Math.max(super.getItemCount(), 0);
    }

    @Override
    public ChatItem getItem(int position) {
        if (position < 0 || position >= super.getItemCount()) {
            return new ChatItem(); // 返回一个空的占位item
        }
        return super.getItem(position);
    }
}

但这只是权宜之计，一定要找到根因彻底修复，不然后续还会出问题。

内容的提问来源于stack exchange，提问作者Walker