If you come from a programming language where allocating objects on the heap is expensive, you may naturally assume that Java’s scheme of allocating everything (except primitives) on the heap is also expensive. However, it turns out that the garbage collector can have a significant impact on increasing the speed of object creation. This might sound a bit odd at first—that storage release affects storage allocation—but it’s the way some JVMs work, and it means that allocating storage for heap objects in Java can be nearly as fast as creating storage on the stack in other languages.
For example, you can think of the C++ heap as a yard where each stakes out its own piece of turf object. This real estate can become abandoned sometime later and must be reused. In some JVMs, the Java heap is quite different; it’s more like a conveyor belt that moves forward every time you allocate a new object. This means that object storage allocation is remarkably rapid. The “heap pointer” is simply moved forward into virgin territory, so it’s effectively the same as C++’s stack allocation. (Of course, there’s a little extra overhead for bookkeeping, but it’s nothing like searching for storage.)
如果你學下過一種因為在堆里分配對象所以開銷過大的編程語言，很自然你可能會假定 Java 在堆里為每一樣東西（除了 primitives）分配內(nèi)存資源的機制開銷也會很大。不過，事實上垃圾收集器能夠深刻影響對象的加速創(chuàng)建。 一開始聽起來有些奇怪——存貯空間的釋放會影響存貯空間的分配，但是這的確是一些 JVMs 的工作方式，并且這意味著 Java 為堆對象分配存貯空間幾乎和別的語言里為棧分配存貯空間一樣地快。
舉個例子，你可以認為 C++的堆就如同一個堆放的工場，在這個工場里，每一個對象都立有的地皮占有權(quán)不久會被廢除無效，并且這塊地皮必須重新加以利用。在Java 的 JVM 里，堆的工作方式完全不同；每次為一個新的對象分配存貯空間的時候，它就更像是一個不斷向前移動的傳送帶。 這就意味著對象存貯空間的分配速度明顯加快。 在這個過程中，“堆指針”簡單地向還沒被占用的空間領域移動，所以非常像 C++里棧的分配方式。（當然，記錄工作會有一點額外的開銷，但是完全不同于 C++里那種在堆放工場里為尋找沒被利用的存貯空間而付出的開銷。）