...
| Wiki Markup |
|---|
Since JDK 1.2, the new generational garbage collector has reduced memory allocation related costs to minimal levels, even lesser than C/C++. Deallocation has also become cheaper such that the cost of garbage collection is commensurate with the number of _live_ objects in the _younger generation_ and not the _total_ number of objects allocated since the last run. Memory is managed in generations to optimize the collection. The younger generation consists of short-lived objects. A minor collection on the younger generation is performed when it fills up with dead objects \[[Oracle 2010a|AA. JavaBibliography#Oracle References#Oracle 10a]\]. |
| Wiki Markup |
|---|
Note that objects in the _younger generation_ that persist for longer durations are _tenured_ and are moved to the _tenured generation_. Very few _younger generation_ objects continue to live through to the next garbage collection cycle; the rest become ready to be collected in the impending collection cycle \[[Oracle 2010a|AA. JavaBibliography#Oracle References#Oracle 10a]\]. |
With generational GCs it is advantageous to use short-lived immutable objects instead of long-lived mutable objects. Object pools are examples of the latter and should be avoided to increase the garbage collector's efficiency. Moreover, object pools can create synchronization problems, deallocations have to be managed explicitly leading to dangers of dangling pointers, and the size of the pool plays a dominant role in mission critical code. Exceptions to this recommendation can be made when the allocation takes longer in comparison, such as when performing multiple joins across databases or when using objects that represent scarce resources such as thread pools and database connections.
...
| Wiki Markup |
|---|
This noncompliant code example (based on \[[Goetz 2004|AA. Java References#GoetzBibliography#Goetz 04]\]) shows a container, {{MutableHolder}}. In {{MutableHolder}}, the instance field {{value}} can be updated to reference a new value using the {{setValue()}} method which makes its existence long-term. This slows down garbage collection. |
...
| Wiki Markup |
|---|
This compliant solution improves by narrowing down the scope of the variable {{buffer}} so that the garbage collector collects the object as soon as it goes out of scope \[[Bloch 2008|AA. Java References#BlochBibliography#Bloch 08]\]. |
| Code Block |
|---|
|
{ // limit the scope of buffer
int[] buffer = new int[100];
doSomething(buffer);
}
|
...
| Wiki Markup |
|---|
\[[API 2006|AA. Java References#APIBibliography#API 06]\] Class {{System}}
\[[Commes 2007|AA. JavaBibliography#Commes References#Commes 07]\] Garbage Collection Concepts and Programming Tips
\[[Goetz 2004|AA. JavaBibliography#Goetz References#Goetz 04]\]
\[[Lo 2005|AA. Java References#LoBibliography#Lo 05]\]
\[[Bloch 2008|AA. Java References#BlochBibliography#Bloch 08]\] Item 6: "Eliminate obsolete object references"
\[[MITRE 2009|AA. Java References#MITREBibliography#MITRE 09]\] [CWE ID 405|http://cwe.mitre.org/data/definitions/405.html] "Asymmetric Resource Consumption (Amplification)" |
...
