動態執行是 Bazel 的一項功能，可同時啟動相同動作的本機和遠端執行作業，並使用第一個完成分支的輸出內容，取消其他分支。它結合了遠端建構系統的執行效能和/或大型共用快取，以及本機執行作業的低延遲時間，為清除和增量建構作業提供兩者兼具的最佳效能。
本頁面說明如何啟用、調整及偵錯動態執行。如果發生以下情況： 必須設定本機和遠端執行作業，並嘗試調整 Bazel 您可以參考這個網頁如果您尚未設定遠端執行作業，請先參閱 Bazel 的遠端執行作業總覽。
是否要啟用動態執行功能？
動態執行模組屬於 Bazel 的一部分，但要使用動態執行 因此，您必須已能在本機和遠端編譯兩者 使用相同的 Bazel 設定
如要啟用動態執行模組，請傳遞 --internal_spawn_scheduler
加到 Bazel這會新增名為 dynamic 的新執行策略。您現在可以將這項做法用於要動態執行的助憶法，例如 --strategy=Javac=dynamic。如要瞭解如何選擇要啟用動態執行作業的助憶法，請參閱下一節。
對於使用動態策略的任何助憶法，系統會從 --dynamic_remote_strategy 旗標取得遠端執行策略，從 --dynamic_local_strategy 旗標取得本機策略。傳球員
--dynamic_local_strategy=worker,sandboxed 會設定本機的
嘗試在工作站或沙箱執行環境中使用工作站或沙箱執行
順序。傳遞 --dynamic_local_strategy=Javac=worker 只會覆寫 Javac 助憶法預設值。遠端版本的運作方式相同。這兩種標記可以
可以多次指定如果動作無法在本機執行，則該動作會
遠端執行，反之亦然。
如果遠端系統有快取，請加上 --dynamic_local_execution_delay 旗標
在遠端系統取得
表示快取命中在快取命中時，避免執行本機執行
預設值為 1000 毫秒，但應調整為比快取命中通常所需時間稍長一點。實際時間取決於遙控器
以及往返時間通常這個值是
提供給特定遠端系統的所有使用者 (除非有部分距離太遠)
增加往返延遲時間您可以使用 Bazel 剖析
功能，方便你查看
快取命中數
動態執行可搭配本機沙箱策略使用，並搭配
永久性工作站。永久磁碟會自動執行
搭配動態執行使用時透過沙箱執行，且不能使用 multiplex
工作站。在 Darwin 和 Windows 系統上，沙箱策略可能會變慢；您可以傳遞 --reuse_sandbox_directories，以減少在這些系統上建立沙箱的額外負擔。
動態執行也可以使用 standalone 策略執行，不過因為
standalone 策略必須在開始執行時採用輸出鎖定，
有效地阻止遠端策略。
--experimental_local_lockfree_output 旗標可透過下列方式解決這個問題
允許本機執行作業直接寫入輸出中，但
遠端執行應該先完成這個動作
如果動態執行的其中一個分支版本先完成但失敗， 整個動作失敗這是有意選擇的做法，可避免本地和遠端執行作業之間的差異遭到忽略。
如要進一步瞭解動態執行作業及其鎖定機制，請參閱 Julio Merino 的優質網誌文章。
何時該使用動態執行？
動態執行需要某種形式的遠端執行系統。 目前無法使用僅快取的遠端系統，因為快取未命中會視為失敗的動作。
並非所有類型的動作都適合遠端執行。最理想的候選項目是本機本身速度較快的項目，例如使用持續性工作站，或是執行速度夠快的項目，以致遠端執行作業的額外負擔成為執行時間的主要因素。由於每個本機執行的動作都會鎖定一定數量的 CPU 和記憶體資源，因此執行不屬於這些類別的動作，只會延遲執行屬於這些類別的動作。
自 5.0.0-pre.20210708.4 版本起，效能分析剖析就會包含有關 worker 執行作業的資料，包括在輸掉動態執行競爭後，完成工作要求所花費的時間。如果您發現動態執行工作站執行緒花費大量時間取得資源，或是在 async-worker-finish 中花費大量時間，表示您可能有某些緩慢的本機動作會延遲工作站執行緒。
上述使用 8 Javac 工作站的設定檔中，看到許多 Javac 工作站
的比賽失敗，並在 async-worker-finish完成工作
。這可能是由於沒有員工的記憶庫
花費了足夠的資源
才能延遲工作站
當只有 Javac 是在動態執行的情況下執行時，大約只有一半的開始執行 因為工人在開始工作之後，就沒辦法趕上賽跑
先前建議的 --experimental_spawn_scheduler 旗標已淘汰。
這項功能會開啟動態執行，並將 dynamic 設為所有
這種記憶法通常會導致這類問題。
成效
動態執行方法假設在本機和遠端都有足夠的資源，因此值得使用額外資源來改善整體效能。不過，如果資源使用量過多，可能會導致 Bazel 本身或執行 Bazel 的機器速度變慢，或是對遠端系統造成意外的壓力。另有 有幾種變更動態執行行為的選項：
--dynamic_local_execution_delay 會將特定數字延遲在本機分支的開頭
毫秒後讀取，
在目前的建構作業期間
發生遠端快取命中如此一來，當快取中可能找到大部分的輸出內容時，建構作業就不會浪費本機資源。視快取品質而定
減少這個數量或許能改善建構速度，但增加本機資源用量時
再複習一下，機構節點
是所有 Google Cloud Platform 資源的根節點
--experimental_dynamic_local_load_factor 是實驗性的進階資源管理選項。該設定的值從 0 到 1，0 會關閉。
設為高於 0 的值時，Bazel 會調整
許多動作等待
如果設為 1，就能以這個數量排定動作，數量不限
都是可用的 CPU (根據 --local_cpu_resources 計費)。值越小，設定的數字越小越好
動作的數量越多，所排定的動作數量就會越少
而且可供使用這聽起來可能不符合直覺，但隨附好遙控器
當同時執行許多動作時，本機執行作業沒有幫助
本機 CPU 較適合用來管理遠端動作
--experimental_dynamic_slow_remote_time 會在遠端分支執行至少這麼久時，優先啟動本機分支。正常情況下
最近排定的動作會優先放送，因為該動作最有可能
不過，如果遠端系統有時會停止運作或花費較多時間
這應該可以建構前進的系統這項功能預設為停用狀態，因為這可能會隱藏應修正的遠端系統問題。請確認
以便監控遠端系統的效能。
--experimental_dynamic_ignore_local_signals 可用於讓遙控器
當局部區域因特定訊號而離開時，分公司接管。這是
主要與工作站資源限制搭配使用 (請參閱
--experimental_worker_memory_limit_mb、
--experimental_worker_sandbox_hardening、
和
--experimental_sandbox_memory_limit_mb)),
例如工作站程序因使用過多資源而終止。
JSON 追蹤記錄設定檔包含 有助於您找出改善出價方式 並在效能和資源用量方面的取捨
疑難排解
動態執行的問題可能很難察覺，也難以偵錯，因為這些問題只會在本機和遠端執行作業的特定組合下出現。--debug_spawn_scheduler 會從動態執行系統中新增額外輸出內容，協助您對這些問題進行偵錯。您也可以調整 --dynamic_local_execution_delay 標記和遠端工作與本機工作的數量，以便更輕鬆地重現問題。
如果您在使用 standalone 進行動態執行時遇到問題
策略、嘗試在不使用 --experimental_local_lockfree_output 的情況下執行
本機動作是採用沙箱機制這可能會使建構速度稍微變慢 (請參閱上方的
您是在 Mac 或 Windows 電腦上，但請移除某些失敗的原因。