failureConditions {
            // JavaExecDebugIntegrationTest.debug session fails without debugger might cause JVM crash
            // Some soak tests produce OOM exceptions
            // There are also random worker crashes for some tests.
            // We have test-retry to handle the crash in tests
            javaCrash = false
        }
    })

fun getTestTaskName(
    testCoverage: TestCoverage,

HSPLkotlinx/coroutines/scheduling/CoroutineScheduler$Worker;->nextInt(I)I
HSPLkotlinx/coroutines/scheduling/CoroutineScheduler$Worker;->pollGlobalQueues()Lkotlinx/coroutines/scheduling/Task;
HSPLkotlinx/coroutines/scheduling/CoroutineScheduler$Worker;->run()V
HSPLkotlinx/coroutines/scheduling/CoroutineScheduler$Worker;->setIndexInArray(I)V
HSPLkotlinx/coroutines/scheduling/CoroutineScheduler$Worker;->setNextParkedWorker(Ljava/lang/Object;)V

		// If the channel reaches above half capacity
		// we spawn more workers. The workers spawned
		// from this main worker routine will exit
		// once the channel drops below half capacity
		// and when it's been at least 30 seconds since
		// we launched a new worker.
		if mainWorker && len(h.logCh) > cap(h.logCh)/2 {
			nWorkers := h.workers.Load()
			if nWorkers < h.maxWorkers {
				if time.Since(h.lastStarted).Milliseconds() > 10 {

type ReplicationStats struct {
	// map of site deployment ID to site replication status
	// for site replication - maintain stats at global level
	srStats *SRStats
	// active worker stats
	workers *ActiveWorkerStat
	// queue stats cache
	qCache queueCache

	pCache proxyStatsCache
	// mrf backlog stats
	mrfStats ReplicationMRFStats
	// for bucket replication, continue to use existing cache

	if (checkOld > 0 && len(p.workers) != checkOld) || n == len(p.workers) || n < 1 {
		// Either already satisfied or worker count changed while we waited for the lock.
		return
	}
	for len(p.workers) < n {
		input := make(chan ReplicationWorkerOperation, 10000)
		p.workers = append(p.workers, input)

		go p.AddWorker(input, &p.activeWorkers)
	}
	for len(p.workers) > n {
		worker := p.workers[len(p.workers)-1]

/// note | 技術細節

這個 Docker 映像是在 Uvicorn 尚未支援管理與重啟死亡 workers 的年代所建立，因此需要用 Gunicorn 搭配 Uvicorn，為了讓 Gunicorn 管理並重啟 Uvicorn workers，而引入了相當多的複雜度。

但現在 Uvicorn（以及 `fastapi` 指令）已支援使用 `--workers`，因此沒有理由使用一個基底 Docker 映像，而不是建置你自己的（而且實際上程式碼量也差不多 😅）。

///

## 部署容器映像 { #deploy-the-container-image }

擁有容器（Docker）映像後，有多種部署方式。

例如：

* 在單一伺服器上使用 Docker Compose
* 使用 Kubernetes 叢集

  /**
   * Returns the {@link Executor} that will be used to run this service. Subclasses may override
   * this method to use a custom {@link Executor}, which may configure its worker thread with a
   * specific name, thread group or priority. The returned executor's {@link
   * Executor#execute(Runnable) execute()} method is called when this service is started and
   * stopped, and should return promptly.

   * Run the service. This method is invoked on the execution thread. Implementations must respond
   * to stop requests. You could poll for lifecycle changes in a work loop:
   *
   * <pre>
   *   public void run() {
   *     while ({@link #isRunning()}) {
   *       // perform a unit of work
   *     }
   *   }
   * </pre>
   *
   * <p>...or you could respond to stop requests by implementing {@link #triggerShutdown()}, which

- **Configuration**: Allows the build structure and work, such as tasks, to be specified. This includes the project model, the DSL and so on.
- **Execution**: Runs the work efficiently. This includes scheduling, execution, caching and so on.

#### Software development platform

特別是，在 **Kubernetes** 上執行時，你多半會選擇不要使用 workers，而是每個容器只跑一個 **Uvicorn 單一處理序**。我會在該章節中進一步說明。

///

## 多個工作處理序 { #multiple-workers }

你可以用命令列選項 `--workers` 來啟動多個 workers：

//// tab | `fastapi`

如果你使用 `fastapi` 指令：

<div class="termy">

```console
$ <font color="#4E9A06">fastapi</font> run --workers 4 <u style="text-decoration-style:solid">main.py</u>