ROS 2 致動器決定何時在可用執行緒上執行準備回呼。回呼組限制哪些回呼可以同時執行。因此，當工作停留在一個互斥組中時，多執行緒致動器幾乎可以表現出序列行為，而重入組則可能暴露不安全的共享狀態存取。
機器人時序失敗通常表現為過時的感測器資料、延遲的控制定時器或服務被阻塞。原因可能是回呼執行、執行前等待時間、鎖、同步服務使用或中介軟體佇列。僅靠執行緒計數無法確定瓶頸。
本指南應與 ROS 2 即時控制指南 及 ROS 2 QoS 指南一起使用。在更改設定前，先追蹤已部署的執行程式。
把執行程式（Executor）當作回呼排程器來對待
訂閱、定時器、服務、客戶端和等待任務在準備好時成為可執行回呼。執行者等待工作，選擇符合條件的回呼，並根據其實現和回呼組規則呼叫。它不會自動推斷機器人需要處理哪些工作。
列出每個回呼的預期速率、最大執行時間、共享資源和截止日期。包含同步客戶端或 Future 物件使用的隱藏回呼。不完整的庫存使得死鎖分析和反應時間宣告不可靠。
單個執行緒使阻擋變得可見
單執行緒致動器一次執行一個回呼。長映象回呼，阻斷磁碟寫入或服務等待，會延遲該執行程式中每隔一次回呼。這種簡潔性對於確定性分析非常有用，當最壞情況的綜合工作負載能夠滿足時。
分別測量準備開始等待和從開始到結束執行的準備程度。如果定時器開始較晚，定時器回呼可能較短，而另一個回呼擁有執行緒。當一個阻塞呼叫造成延遲時，平均 CPU 利用率可能保持較低。
| 症狀 | 很可能的層 | 第一次測量 | 共同原因 |
|---|---|---|---|
| 所有回呼均暫停 | 單執行執行緒 | 回呼時長 | 阻斷 I/O |
| 只有一組進行連載 | 回呼組合 | 組和執行緒跟蹤 | 預設組 |
| 服務呼叫結束通話 | 依賴迴圈 | Future 物件與回呼組歸屬 | 自死鎖 |
| 新訊息遲到了 | 佇列或執行者 | 回呼時的樣本年齡 | 慢消費者 |
| 在高負載下錯過截止日期 | 排程與競爭 | 尾部等待時間 | 共享鎖或 CPU 壓力 |
多執行緒並不保證並行回呼
多執行緒致動器可以在多個執行緒上執行合格的回呼，但呼叫組的限制仍然適用。如果所有實體都使用節點預設的互斥組，即使存在多個執行執行緒，它們也無法並行執行。
在實體建立時檢查組分配，並確認該組仍與執行者關聯。目前 ROS 2 執行程式概念 應被讀取用於部署的發行版，因為實現行為可能會演變。
保護序列使用互斥群
互斥的回呼組防止其回呼同時執行。這可以保護非執行緒安全狀態而無需單獨鎖，並保持組內的順序假設。但也可能導致無關的長時間工作，延遲關鍵計時器。
按實際併發需求進行組回呼，而非單純按節點。將必須序列化的裝置事務放在一起，並在共享狀態設計允許時分離獨立遙測或昂貴的處理。記錄每個組為何是互斥的。
重入組需要執行緒安全流程碼
重入組允許回呼，包括同一回呼的多個例項，重疊。它可以改善獨立工作的併發性，但不能使存取的庫、緩衝區或裝置執行緒安全。競態條件可能破壞狀態，而基準測試速度更快。
審查共享變數、釋出者、客戶端、裝置控制程式碼和第三方庫。使用有界同步，避免在 I/O 之間保持鎖定。透過重複重疊請求和執行緒淨化器或等效測試來強調。
| 組別選擇 | 併發 | 有用的 | 主要風險 |
|---|---|---|---|
| 互斥 | 小組裡有一次回電 | 有序裝置存取 | 隱藏序列化 |
| 重返者 | 重疊回呼 | 獨立無國籍工作 | 資料種族 |
| 獨立的排他性群體 | 跨群的平行 | 獨立序列裝置 | 跨組共享鎖 |
| 專用執行程式（Executor） | 獨立執行緒池 | 關鍵路徑隔離 | 協調開銷 |
| 非 ROS 工作人員 | 顯式切換 | 分組或批次工作 | 佇列所有權 |
避免同步自死鎖
發出同步服務請求的回呼可能會等待必須在同一互斥組內執行的反應回呼。等待的回呼保留了該組的資格，因此反應無法執行。類似的迴圈也會發生在 Future 物件和 Action 之間。
傾向於在回呼中採用非同步流，將依賴回呼放入相容的組中，或使用精心設計的獨立執行程式。繪製等待圖並測試超時。新增執行緒不會打破組級排除迴圈。
執行和等待分佈的大小
每次回呼，記錄呼叫率、執行時間百分位、最大觀測時間和準備等待。儘可能新增 CPU 親和力、執行緒身份和鎖等待。執行緒池大小應根據併發度和阻塞行為確定，而非僅根據處理器核心數數來計算。
包含序列化、中介軟體獲取、記憶體分配、紀錄和快取效果。執行足夠長以暴露熱限流和後台作業。高吞吐量結果可能與不可接受的控制尾延遲共存。
優先順序不是自動的
僅僅選擇執行者並不保證作業系統執行緒優先順序、回呼優先順序或有界搶佔。關鍵回呼和盡力回呼可以共享工作執行緒或鎖。根據執行者的行為，準備就緒的低重要性回呼可能會在控制定時器之前執行。
在截止日期重要時，隔離關鍵工作，有意識地設定排程和親和力，移除阻塞操作，並在最壞情況下爭用時進行測量。 ROS 2 即時展示 描述的是支援實踐，而非任意應用的認證。
將 QoS 延遲與執行程式（Executor）延遲區分開
QoS 影響相容性、保留和傳輸行為。執行程式影響已準備好回呼的執行時間。兩者都可能增加取樣年齡。將可靠改為盡力可能減少網路積壓，但無法修復被互斥單元阻塞的回呼。
將源時間戳和序列號帶入回呼。記錄接收準備情況、回呼開始和消耗時間。這樣可以定位中介軟體交付前後延遲，防止調錯層。
用 trace 和受控負載診斷
跟蹤回呼準備、開始和結束事件、執行執行緒、組身份及相關鎖。一次新增一個負載源：高速感測器、服務突發、慢 I/O、 CPU 負載和網路丟失。在更改設計前保留失敗的跟蹤。
然後移動或拆分一個回呼組，替換一個同步依賴，或解除安裝一個阻塞任務。重複同樣的工作負載。自適應測量比一次性改變多個時序層的完全重寫提供了更有力的證據。
將即時路徑與便利工作隔離開來
視覺化、參數服務、診斷、袋記錄和模型推斷如果共享執行執行緒、鎖或記憶體，可能會干擾控制。跨入專用控制執行緒或執行者時，使用有界佇列和明確所有權。
隔離並不能消除通訊延遲。定義最新的有效狀態，在每個邊界處丟棄策略和看門狗。驗證盡力而為的工作無法填滿被關鍵路徑佔用的佇列。
按截止日期和資料年齡接受
統計吞吐量，但接受度基於回呼等待、執行尾部、錯過的定時器週期、樣本在使用時的資料年齡和過載恢復。軟體和硬體更換後測試同一個回呼圖。
釋出包含組、執行緒池、排程、共享鎖和最壞情況工作負載的執行者合約。
評估“ROS 2 執行程式（Executor）與回呼組：機器人時序指南”時，還應儲存模型版本、機器人設定、校正檔案、測試日期和全部試驗記錄。
只有把這些持續投入與單位成功任務的價值比較，才能判斷方案是否適合擴大。
上線後仍要持續檢查分佈變化、感測器漂移、機械磨損和人工接管原因。
實際專案還應指定資料、模型、控制器和安全流程的負責人，並預先定義回復條件。責任邊界、審批記錄與變更紀錄越清楚，故障發生後越容易停止擴散、定位原因並安全恢復。
- 清點每個回呼及其隱藏依賴。
- 跟蹤等待和執行時間分別計算。
- 地圖回呼組和共享資源。
- 注入 CPU、 I/O、服務和感測器負載。
- 按截止日期和資料新鮮度接受。
常見問題
多執行緒致動器會並行執行每個回呼嗎？
不是。呼叫組規則、現成工作、執行緒計數和共享鎖決定了實際併發。
每次回呼都能留在預設組裡嗎？
它可以，但預設的互斥群可能會序列化工作，從而破壞預期的並行性。
Reentrant 組總是更快嗎？
不允許。它只允許重疊；爭用、競賽和額外同步會降低效能或正確性。
Best Effort QoS 修復執行程式（Executor）延遲問題嗎？
當延遲來自回呼排程、鎖定或阻塞程式碼時，就不行了。測量兩層。
首先應該測量什麼？
每次回呼時，測量源資料年齡、準備開始等待、執行時長、執行緒和回呼組。
執行程式時序證據邊界
致動器時序取決於 ROS 分佈、 RMW、作業系統、硬體、回呼程式碼和工作負載。測量部署的圖；僅靠致動器設定並不能保證即時。