常見問題
是否可以在多個執行緒或多個程序中執行作業？
有三種方法可以實現這一點——但我們建議在分析此類需求時謹慎（這真的有必要嗎？）。
-
向步驟中新增一個
TaskExecutor。用於配置步驟的 `StepBuilder` 具有可以設定的“taskExecutor”屬性。只要步驟本質上是可重新啟動的（實際上是冪等的），此方法就有效。並行作業示例展示了它在實踐中如何工作——這使用“程序指示器”模式在業務事務內部將輸入記錄標記為已完成。 -
使用
PartitionStep將您的步驟執行顯式地分配給多個 Step 例項。Spring Batch 為此（PartitionHandler）提供了主要策略的本地多執行緒實現，這使其成為 I/O 密集型作業的絕佳選擇。請記住，對於以這種方式執行的步驟中的有狀態元件，請使用scope="step"，以便為每個步驟執行建立單獨的例項，並且執行緒之間沒有交叉通訊。 -
使用
spring-batch-integration模組中實現的遠端分塊方法。這需要一些持久的中介軟體（例如 JMS）來實現驅動步驟和遠端工作程式之間可靠的通訊。基本思想是在驅動程序上使用特殊的ItemWriter，並在工作程序上使用監聽器模式（透過ChunkProcessor）。
如何使 ItemReader 執行緒安全？
您可以同步 read() 方法（例如，透過將其包裝在一個執行同步的委託器中）。請記住，您將失去可重新啟動性，因此最佳實踐是將步驟標記為不可重新啟動，並且為了安全（和高效），您還可以將讀取器的 saveState=false 設定為 false。
Spring Batch 對靈活策略和預設實現的使用有什麼理念？你能為這個或那個屬性新增一個公共 getter 嗎？
Spring Batch 為框架開發人員（而不是業務邏輯實現者）提供了許多擴充套件點。我們期望客戶端建立自己更具體的策略，這些策略可以插入以控制諸如提交間隔 ( CompletionPolicy )、處理異常的規則 ( ExceptionHandler ) 等等。
通常，我們試圖勸阻使用者擴充套件框架類。Java 語言在將類和介面標記為內部方面沒有給我們太多的靈活性。通常，您可以期望 org.springframework.batch.* 包中原始碼樹頂層的任何內容都是公共的，但不一定是可子類化的。不鼓勵擴充套件我們大多數策略的具體實現，而傾向於組合或分叉方法。如果您的程式碼只能使用 Spring Batch 的介面，那將為您提供最大的可移植性。
Spring Batch 與 Quartz 有何不同？它們是否都可以在解決方案中佔有一席之地？
Spring Batch 和 Quartz 具有不同的目標。Spring Batch 提供處理大量資料的功能，而 Quartz 提供排程任務的功能。因此，Quartz 可以補充 Spring Batch，但它們不是相互排斥的技術。一個常見的組合是使用 Quartz 作為 Spring Batch 作業的觸發器，使用 Cron 表示式和 Spring Core 便利的 SchedulerFactoryBean。
如何使用 Spring Batch 排程作業？
使用排程工具。市面上有許多這樣的工具。例如：Quartz、Control-M、Autosys。Quartz 沒有 Control-M 或 Autosys 的所有功能——它應該輕量級。如果你想要更輕量級的，你只需使用作業系統（cron、at 等）。
可以使用 Spring Batch 的作業-步驟模型和 Spring Batch 中的非順序功能來實現簡單的順序依賴關係。我們認為這很常見。事實上，它使得糾正排程器的一個常見誤用變得更容易——配置了數百個作業，其中許多不是獨立的，而只是依賴於另一個。
Spring Batch 如何透過並行處理或其他方式幫助專案最佳化效能和可伸縮性？
我們認為這是 Job 或 Step 的職責之一。Step 的特定實現處理分解業務邏輯並在並行程序或處理器之間有效共享它的問題（請參閱 PartitionStep）。這裡有許多技術可以發揮作用。其本質只是一組對分散式代理的併發遠端呼叫，這些代理可以處理一些業務處理。由於業務處理通常已經模組化——例如，輸入一個專案，處理它——Spring Batch 可以透過多種方式策略化分發。我們有過一些經驗的一種實現是一組處理業務處理的遠端 Web 服務。我們將輸入的主鍵的特定範圍傳送到許多遠端呼叫中的每一個。相同基本策略適用於任何 Spring Remoting 協議（純 RMI、HttpInvoker、JMS、Hessian 等），只需更改執行層配置中的幾行程式碼。
如何使用訊息傳遞來擴充套件批處理架構？
現有專案的大量實踐證據表明，批處理的管道方法非常有益，可提高彈性和高吞吐量。我們經常面臨任務關鍵型應用程式，其中審計跟蹤至關重要，並且需要保證處理，但在負載下的效能受到極其嚴格的限制，或者高吞吐量帶來競爭優勢。
Matt Welsh 的工作表明，分階段事件驅動架構 (SEDA) 比更僵化的處理架構具有巨大的優勢，並且面向訊息的中介軟體（JMS、AQ、MQ、Tibco 等）為我們提供了大量的開箱即用彈性。在下游和上游階段之間存在反饋的系統中，尤其有益，因此可以調整消費者數量以適應需求量。那麼這如何適應 Spring Batch 呢？spring-batch-integration 專案在 Spring Integration 中實現了這種模式，並且可以用於擴充套件任何處理許多專案的步驟的遠端處理。特別是，請參閱“chunk”包，以及其中的 ItemWriter 和 ChunkRequestHandler 實現。
