使用Java的一個主要優點就是無需擔心廢棄對象，即，讓Java運行時負責Java對象的內存管理。
這是通過讓Java運行時對不再使用的Java對象進行垃圾收集而實現的。
垃圾收集是一個比較復雜的過程。通常，Java運行時會遍歷堆，檢查不再被其他對象引用、從而可以安全刪除的對象，然而，由於垃圾收集占用CPU周期，所以它可能會影響應用程序代碼的執行。即，如果在執行應用程序代碼的過程中執行垃圾收集，則應用程序代碼的響應時間可能延長。這會導致用戶事務延遲的延長。更為糟糕的是，因為用戶不知道何時會進行垃圾收集，因此延遲的延長是不可預知的。
實時應用程序有嚴格的時間要求，即，它們必須在確定的、已知的延遲條件下執行應用程序代碼。因此垃圾收集所引起的不可預知的延遲延長就成為一個問題。
那麼這個問題的解決方案是什麼呢？一個明顯的解決方案就是不要對實時應用程序使用Java。這是一個下下選。作為一種編程語言和一個開發平台，Java具有許多優點。我們應該能夠解決Java中的這個問題。
另一種解決方案是在Java中使用另一種內存管理方法來代替垃圾收集程序。RTSJ (Real-Time Specification for Java)定義了immortal memory和scoped memory的概念。不朽內存(Immortal memory)是從不進行垃圾收集的內存，只要JVM存在，它就也存在。作用域內存(Scoped memory)則是按塊分配和釋放的內存。即，用戶顯式地創建一個內存區域來存放對象，該區域中的對象將在該區域被銷毀時釋放。不管是不朽內存還是作用域內存，都不需要進行垃圾收集。不過，這也有一個缺點：管理內存的重擔又落在了用戶身上，就像C/C++應用程序一樣。這個代價仍然很高。有沒有更好的方法呢？
我們來重新考慮一下垃圾收集。垃圾收集的主要問題是它所引起的不可預知的延遲峰值。能否避免這種不可預知的行為呢？或者，能否限制（即約束）這種不可預知的行為呢？通過更頻繁地執行垃圾收集，我們就可以限制最大延遲時間。這就是WLRT所采用的方法。因此，垃圾收集成為一項可預知的任務，具有已知的代價，從而使實時開發人員可以根據需要進行考慮和建模。而且，更為重要的是，我們沒有犧牲Java的易用性。
注：應該注意的是，雖然有垃圾收集和其他的內存管理技術，Java程序仍然可能存在內存洩漏。例如，在下述情況下：在不需要組件對象時，卻沒有將其從容器中移除。
