Thank you, I know the role of TaskQueue, but the comment about "normal queue"
on the TaskQueue class is still incomprehensible.
In the java.util.concurrent.ThreadPoolExecutor#execute method, the comment
mentions: "3. If we cannot queue task, then we try to add a new thread. If it
fails, we know we are shut down or saturated and so reject the task.". Explain
that the JDK prioritizes putting tasks into the queue rather than creating
threads first, which is not consistent with the statement that "normal queue"
mentioned in TaskQueue prioritizes thread creation.
java.util.concurrent.ThreadPoolExecutor#execute:
/**
* Executes the given task sometime in the future. The task
* may execute in a new thread or in an existing pooled thread.
*
* If the task cannot be submitted for execution, either because this
* executor has been shutdown or because its capacity has been reached,
* the task is handled by the current {@code RejectedExecutionHandler}.
*
* @param command the task to execute
* @throws RejectedExecutionException at discretion of
* {@code RejectedExecutionHandler}, if
the task
* cannot be accepted for execution
* @throws NullPointerException if {@code command} is null
*/
public void execute(Runnable command) {
if (command == null)
throw new NullPointerException();
/*
* Proceed in 3 steps:
*
* 1. If fewer than corePoolSize threads are running, try to
* start a new thread with the given command as its first
* task. The call to addWorker atomically checks
runState and
* workerCount, and so prevents false alarms that would add
* threads when it shouldn't, by returning false.
*
* 2. If a task can be successfully queued, then we still
need
* to double-check whether we should have added a thread
* (because existing ones died since last checking) or that
* the pool shut down since entry into this method. So we
* recheck state and if necessary roll back the enqueuing if
* stopped, or start a new thread if there are none.
*
* 3. If we cannot queue task, then we try to add a new
* thread. If it fails, we know we are shut down or
saturated
* and so reject the task.
*/
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();
if (! isRunning(recheck) && remove(command))
reject(command);
else if (workerCountOf(recheck) == 0)
addWorker(null, false);
}
else if (!addWorker(command, false))
reject(command);
}
------------------ Original ------------------
From:
"Tomcat Users List"
<[email protected]>;
Date: Tue, Oct 26, 2021 02:33 AM
To: "users"<[email protected]>;
Subject: Re: About the comment of org.apache.tomcat.util.threads.TaskQueue
tianshuang,
On 10/23/21 23:44, Poison wrote:
> Tomcat version: 8.5.72
>
>
> org.apache.tomcat.util.threads.TaskQueue&nbsp;source
code:&nbsp;https://github.com/apache/tomcat/blob/8.5.72/java/org/apache/tomcat/util/threads/TaskQueue.java#L33
>
>
> In the comments of the&nbsp;TaskQueue&nbsp;class, it mentions "If
you use a normal queue, the executor will spawn threads when there are idle
threads and you wont be able to force items onto the queue
itself.".&nbsp;But when we use java.util.concurrent.LinkedBlockingQueue, it
will be put into the queue by default instead of creating threads. What queue
does the normal queue in the comment refer to?
Just looking at the class definition, I think "normal queue" means "an
instance of another subclass of BlockingQueue<Runnable>".
The TaskQueue class has a "force" method which does something like
"offer" but behaves differently. Tomcat can use this internally instead
of having to only use the more limited "offer" method of the Queue
interface.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
