线程池提交一个任务占多大内存？

我们知道提交任务到线程池有两种方法，一种是execute，一种是submit

这两种提交方式占用的内存是一样大的吗？一个空任务究竟占多少内存？

通过源码分析一下

execute

public static void main(String[] args) {
    ThreadPoolExecutor threadPoolExecutor =
            new ThreadPoolExecutor(8, 8, 15, TimeUnit.MINUTES, new LinkedBlockingQueue(), new ThreadPoolExecutor.CallerRunsPolicy());
    for (int i = 0; i  {
            // 乱写...
            int p = finalI;
            LockSupport.park();
        });
    }
    LockSupport.park();
}

这是一段典型的使用execute往线程池中提交任务的代码，这里是提交了20w个任务

execute的源码如下：

// ThreadPoolExecutor.execute
public void execute(Runnable command) {
    // 判空
    if (command == null)
        throw new NullPointerException();
    int c = ctl.get();
    // 当前线程数没达到核心线程数
    if (workerCountOf(c) < corePoolSize) {
        // 创建核心线程
        if (addWorker(command, true))
            return;
        c = ctl.get();
    }
    // 尝试往阻塞队列中提交任务
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        // 二次检查，防止进入execute之后，线程池shutdown了
        if (! isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);
    }
    // 阻塞队列放不下，创建非核心线程
    else if (!addWorker(command, false))
        reject(command);
}

execute体现的就是线程池的工作原理，addWorker中有更复杂的逻辑来保证worker的原子性地插入，这个逻辑以后有机会可以聊聊

那么使用execute提交一个任务，这个任务究竟多大呢？

我们使用得最多的就是使用lambda表达式来提交任务

threadPoolExecutor.execute(() -> {
	// ...
});

那么这个lambda实例占用多少个字节呢？

16字节；在开了指针压缩的情况下，对象头占12个字节，4个字节用于填充补齐到8的整数倍，由于这个lambda实例中没有其他成员变量了，所以它就是占据16个字节

除此之外，如果使用的是LinkedBlockingQueue阻塞队列来存放任务，那么还涉及到LinkedBlockingQueue中的Node，LinkedBlockingQueue会使用这个Node来封装任务

static class Node {
    E item;

    /**
     * One of:
     * - the real successor Node
     * - this Node, meaning the successor is head.next
     * - null, meaning there is no successor (this is the last node)
     */
    Node next;

    Node(E x) { item = x; }
}

这个Node占多少字节呢？

24个字节；同样对象头占12字节，item是一个4字节的引用，next也是一个4字节的引用，一共20字节，4个字节用于填充对齐，所以一个node对象是24字节

所以在使用execute且阻塞队列是LinkedBlockingQueue时一个任务占用40个字节

如果execute20w个任务，会占用800w个字节，约7.6MB内存

堆快照如下：

如果是使用ArrayBlockingQueue的话，只有lambda实例这一个开销，所以只会使用320w个字节，约3.05MB内存，比起LinkedBlockingQueue少了一倍不止

submit

接下来分析一下submit

// AbstractExecutorService.submit
public Future submit(Runnable task) {
    if (task == null) throw new NullPointerException();
    RunnableFuture ftask = newTaskFor(task, null);
    execute(ftask);
    return ftask;
}

submit中调用了newTaskFor方法来返回一个ftask对象，然后execute这个ftask对象，newTaskFor代码如下：

// AbstractExecutorService.newTaskFor
protected  RunnableFuture newTaskFor(Runnable runnable, T value) {
    return new FutureTask(runnable, value);
}

newTaskFor又调用我们熟悉的FutureTask的有参构造器来创建一个futureTask实例，代码如下：

// FutureTask有参构造器
public FutureTask(Runnable runnable, V result) {
    this.callable = Executors.callable(runnable, result);
    this.state = NEW;       // ensure visibility of callable
}

这个有参构造器中又调用了Executors的静态方法callable创建一个callable实例来赋值给futureTask的callable属性，代码如下：

// Executors.callable
public static  Callable callable(Runnable task, T result) {
    if (task == null)
        throw new NullPointerException();
    return new RunnableAdapter(task, result);
}

最后还是使用了RunnableAdapter来包装这个task，代码如下：

// Executors.RunnableAdapter类
static final class RunnableAdapter implements Callable {
    final Runnable task;
    final T result;
    RunnableAdapter(Runnable task, T result) {
        this.task = task;
        this.result = result;
    }
    public T call() {
        task.run();
        return result;
    }
}

梳理一下整个流程，run和call的关系的伪代码如下

// submit
run(){
    // RunnableAdapter.call
	call(){
        // task.run
		run(){
			// 实际的任务
		}
	}
}

为什么要这么麻烦封装一层又一层呢？

可能是为了适配。submit的返回值是futureTask，但是我们传给submit的是个runnable，然后submit会把这个runnable继续传给futureTask，futureTask的结果值是null，但是又由于futureTask的run方法已经被重写成执行call方法了（具体见浅谈FutureTask实现原理），所以只能在call方法里面跑我们真正的run方法了

所以最后用了submit方法之后，会多出两类对象，一个是FutureTask，一个是RunnableAdapter

FutureTask的成员变量如下：

/** The underlying callable; nulled out after running */
private Callable callable;
/** The result to return or exception to throw from get() */
private Object outcome; // non-volatile, protected by state reads/writes
/** The thread running the callable; CASed during run() */
private volatile Thread runner;
/** Treiber stack of waiting threads */
private volatile WaitNode waiters;

一个FutureTask对象占用的字节数是12+4+4+4+4=28个字节，还需要4个字节做填充，所以一共是32个字节

RunnableTask的成员变量如下：

final Runnable task;
final T result;

一个RunnableTask对象占用的字节数是12+4+4=20个字节，同样需要4个字节做填充，所以一共是24个字节

所以在使用submit且阻塞队列是LinkedBlockingQueue时一个任务占用96个字节

如果submit20w个任务，会占用1920w个字节，约18.31MB内存

如果使用的是ArrayBlockingQueue会省去Node的占用的内存

lambda中没有使用上下文中的其他变量时

public static void main(String[] args) {
    ThreadPoolExecutor threadPoolExecutor =
            new ThreadPoolExecutor(8, 8, 15, TimeUnit.MINUTES, new LinkedBlockingQueue(), new ThreadPoolExecutor.CallerRunsPolicy());
    for (int i = 0; i  {
            // 乱写...
            // int p = finalI;
            LockSupport.park();
        });
    }
    LockSupport.park();
}

如果在lambda中没有使用到上下文的其他变量时，是不会重复创建lambda实例的，只会创建一个

只会创建一个lambda实例

如果配合上ArrayBlockingQueue以及execute，提交20w个任务的空间复杂度可以降至O(1)

因为20w个任务的实例都是同一个

总结

如果是lambda中没有上下文变量，使用的队列是ArrayBlockingQueue，提交方式是execute，那么空间复杂度可以达到O(1)；如果lambda中有上下文变量，每次提交任务都会创建一个新的lambda实例；如果使用的队列是LinkedBlockingQueue，那么还要算上LinkedBlockingQueue的Node实例的开销；如果提交的方式是submit，那么还要算上FutureTask和RunnableAdapter的开销

当然这里只是浅层地讨论了一下创建一个空任务所占用的内存大小，如果是更加复杂的任务，任务内的内存开销需要算上

如果错误，请斧正