【深入理解 ByteBuf 之三 接口&类拆解】1. ObjectPool 接口设计剖析

想了一下，我决定还是做更细化的拆解，也看了很多源码剖析的文章¹，以及我之前也写过，一个令人难受的点就是通篇的代码解释，通篇没什么头绪，我看着没头绪，感觉写的也没什么头绪，就是在硬看硬写，看完之后仍然不知云云，不得要领，无法复刻，写完之后的感觉也是。
在步入第三部分 接口&类的解析，我决定对每个一个接口&类的定义实现都进行拆解和剖析聊一聊这样设计的好处和原因²，并拆分为小块进行整理，以小见大。
最终应该会整理出一版最终的设计脉络。

ObjectPool 接口设计

ObjectPool 接口实际上是对整体的池化分配做了整体的抽象和解耦

通过定义两个接口 ObjectCreator 和 Handle 接口 将创建和回收解耦可以灵活提供各类实现。

整体的控制逻辑在 Recycler 中进行实现。

package io.netty.util.internal;

import io.netty.util.Recycler;

/**
 * Light-weight object pool.
 * T 的类型是要池化的资源的类型
 * 对象池一般由 T 类持有，比如 PooledUnsafeDirectByteBuf 、 PooledDirectByteBuf
 * 对应 T 类持有静态的对象池，可供直接分配调用  io.netty.buffer.PooledUnsafeDirectByteBuf#newInstance(int)
 * @param <T> the type of the pooled object
 */
public abstract class ObjectPool<T> {

    ObjectPool() { }

    /**
     * Get a {@link Object} from the {@link ObjectPool}. The returned {@link Object} may be created via
     * {@link ObjectCreator#newObject(Handle)} if no pooled {@link Object} is ready to be reused.
     * 获取一个 T 对象池中。
     * 如果对象池中没有可重用的对象，这个返回的对象可能会通过 ObjectCreator#newObject 方法获取
     */
    public abstract T get();

    /**
     * Handle for an pooled {@link Object} that will be used to notify the {@link ObjectPool} once it can
     * reuse the pooled {@link Object} again.
     * 用于表示池化的句柄 Handle ， 用于通知对象池可以再次重用已经池化的对象
     * @param <T>
     */
    public interface Handle<T> {
        /**
         * Recycle the {@link Object} if possible and so make it ready to be reused.
         * 回收方法，如果可能得话回收 T 对象自己，并使其准备好可以再次重用
         * *
         */
        void recycle(T self);
    }

    /**
     * Creates a new Object which references the given {@link Handle} and calls {@link Handle#recycle(Object)} once
     * it can be re-used.
     * 创建一个新的对象，引用给的的 handle 并且在可以重新使用是调用 Handle 的 recycle 方法
     * @param <T> the type of the pooled object
     */
    public interface ObjectCreator<T> {

        /**
         * Creates an returns a new {@link Object} that can be used and later recycled via
         * {@link Handle#recycle(Object)}.
         * 创建一个新的可用对象返回， 可以通过 recycle 方法进行回收
         */
        T newObject(Handle<T> handle);
    }

    /**
     * Creates a new {@link ObjectPool} which will use the given {@link ObjectCreator} to create the {@link Object}
     * that should be pooled.
     * 创建一个新的对象池，并通过给定的 ObjectCreator 去创建应该被池化的对象
     */
    public static <T> ObjectPool<T> newPool(final ObjectCreator<T> creator) {
        return new RecyclerObjectPool<T>(ObjectUtil.checkNotNull(creator, "creator"));
    }

    /**
     * 一个默认的对象池实现，持有一个 recycler 回收器，通过 recycler 执行对象获取
     */
    private static final class RecyclerObjectPool<T> extends ObjectPool<T> {
        private final Recycler<T> recycler;

        RecyclerObjectPool(final ObjectCreator<T> creator) {
             recycler = new Recycler<T>() {
                @Override
                protected T newObject(Handle<T> handle) {
                    return creator.newObject(handle);
                }
            };
        }

        @Override
        public T get() {
            return recycler.get();
        }
    }
}

这段代码涉及到对象池的设计，包括主要的接口 ObjectPool 以及与之关联的 Handle 和 ObjectCreator 接口。同时，通过内部的 RecyclerObjectPool 类实现了具体的对象池。

设计思路解析：

1. ObjectPool 接口： 该接口定义了对象池的基本操作，主要包括从池中获取对象的 get 方法。它是一个泛型接口，这使得它可以处理各种类型的对象。

2. Handle 接口： 这是一个用于处理池化对象的句柄接口，定义了回收对象的方法 recycle。通过这个接口，实现了对象的回收与重用。

3. ObjectCreator 接口： 该接口定义了创建新对象的方法 newObject，它接收一个 Handle 对象，用于在创建对象时将其与对象池关联起来。这样，新创建的对象就能够被池化并通过 Handle 进行回收。

4. RecyclerObjectPool 类： 这是 ObjectPool 接口的具体实现类，通过内部的 Recycler 类来管理对象的创建和回收。将具体的对象创建逻辑放在 Recycler 中的好处是可以实现更灵活的对象创建策略，例如通过对象池管理的对象进行初始化。

5. Recycler 类： 这是一个抽象类，实现了对象的创建和回收逻辑。通过继承该类，可以实现具体类型对象的创建和回收方法。将这部分逻辑抽象到 Recycler 中的好处是可以灵活地扩展和定制对象的创建和回收行为。

设计的好处和意义：

• 模块化和可扩展性： 将对象池的不同职责划分到不同的接口和类中，使得每个部分都可以单独扩展或替换，增强了系统的模块化和可扩展性。

• 解耦和复用： 将对象的创建、回收和池的管理分离，提高了代码的可维护性和复用性。例如，可以通过实现不同的 Recycler 子类来定制对象的创建和回收策略。

• 灵活性： 通过使用 ObjectCreator 和 Handle 接口，使得对象的创建和回收可以被不同的实现灵活地处理，而不是硬编码在对象池中。

• 对于特定逻辑的集中处理： 将对象创建和回收逻辑放在 Recycler 类中，使得这些逻辑能够集中处理，有利于代码的维护和理解。同时，RecyclerObjectPool 作为具体的对象池实现类，主要负责管理 Recycler 的使用，起到了组织和管理的作用。

总体来说，这种设计提供了更灵活、可扩展、可维护的对象池实现。大概……就是因为好拓展罢了，反正我觉得并不利于理解