Comparison of Java and C++: Difference between revisions

Revision as of 16:13, 17 October 2023

Revision as of 14:53, 18 October 2023

Line 320:

** In C++, it is possible to have a [[dangling pointer]], a stale [[Reference (computer science)|reference]] to an object that has already been deallocated. Attempting to use a dangling pointer typically results in program failure. In Java, the garbage collector will not destroy a referenced object.

** In C++, it is possible to have uninitialized primitive objects. Java enforces default initialization.

** In C++, it is possible to have an allocated object to which there is no valid reference. Such an [[unreachable object]] cannot be destroyed (deallocated), and results in a [[memory leak]]. In contrast, in Java an object will not be deallocated by the garbage collector ''until'' it becomes unreachable (by the user program). (''[[Weak reference]]s'' are supported, which work with the Java garbage collector to allow for different ''strengths'' of reachability.) Garbage collection in Java prevents many memory leaks, but leaks are still possible under some circumstances.<ref>{{cite web|url=http://www-128.ibm.com/developerworks/rational/library/05/0816_GuptaPalanki/ |title=Java memory leaks – Catch me if you can |author1=Satish Chandra Gupta |author2=Rajeev Palanki |publisher=IBM DeveloperWorks |date=16 August 2005 |access-date=2015-04-02|archive-url=https://web.archive.org/web/20120722095536/http://www.ibm.com/developerworks/rational/library/05/0816_GuptaPalanki/ |archive-date=2012-07-22}}</ref><ref>[https://web.archive.org/web/20140205030750/http://www.openlogic.com/wazi/bid/188158 How to Fix Memory Leaks in Java] by Veljko Krunic (10 Mar 2009)</ref><ref>[https://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java Creating a memory leak with Java] on [[stackoverflow]].com</ref> The automatic garbage collector may give the false impression that in Java one does not need to think about memory management.{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} However this is not quite true.{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} Loosely speaking, this is because a program can have "memory leaks", more formally known as "unintentional object retentions".{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} An example of a memory leak that may occur is for a program that has been written without any logical errors, except that it did not eliminate obsolete references.{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} This results in higher use of garbage collector activity, higher [[memory footprint]].{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} In extreme circumstances, this problem can lead to an OutOfMemoryError, but this rarely happens.

{{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} The solution to this is to null out object references. {{sfn|Bloch|2018|loc=Chapter §2 Item 7: Eliminate obsolete references|pp=123-125}} A second common reason for memory leak is the use of cache that has become no longer relevant. The solution to memory leaks due to using old cache is to represent the cache using a <code>WeakHashMap</code>.