DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
  1. DZone
  2. Coding
  3. Java
  4. Java and Memory Leaks

Java and Memory Leaks

Peter Lawrey user avatar by
Peter Lawrey
·
Jul. 25, 11 · Interview
Like (1)
Save
Tweet
Share
9.35K Views

Join the DZone community and get the full member experience.

Join For Free

The term "memory leak" is used in Java in a manner which is different to how it is used in other languages. What does a "memory leak" mean in general terminology and how is it used in Java?

Wikipedia definition

A memory leak, in computer science (or leakage, in this context), occurs when a computer program consumes memory but is unable to release it back to the operating system.
The JVM reserves the heap as virtual memory on startup and doesn't gives that memory back until it exits. This virtual memory turns into main memory as it is used. This is why the virtual size and the resident size for a JVM can be very different and the resident memory can grow without the virtual memory changing.

In object-oriented programming, a memory leak happens when an object is stored in memory but cannot be accessed by the running code.

The GC can always find every object on the heap, even those which are not reachable to the application. As such there is no object which is not reachable to running code.

however, many people refer to any unwanted increase in memory usage as a memory leak, though this is not strictly accurate from a technical perspective.

In Java, the amount of memory required cannot be determined without a full GC. It is normal to see the "used" memory of a Java application sawtooth. Returning to the same amount of memory used after each GC indicates the memory required has not increased.


A memory leak can diminish the performance of the computer by reducing the amount of available memory. Eventually, in the worst case, too much of the available memory may become allocated and all or part of the system or device stops working correctly, the application fails, or the system slows down unacceptably due to thrashing.

This is how the term is used in Java. There is a reduction in available memory, conclusion: it is a memory leak.

But is it really a memory leak?

Examples of "memory leaks" in Java

Recently, two questions were asked on StackOverflow which illustrate a variety of views over what a "memory leak" means in Java.

Is Go subject to the same subtle memory-leaks that Java is?
Creating a memory leak in Java

In the first article there was a view expressed that a "memory leak" is when an application holds references to objects which are no longer needed. Another view was that the JVM itself doesn't have memory leaks.

In the second article there were many examples of how the JVM could be used to hide away memory usage or operations which would consume memory. Examples included File.deleteOnExit(), creating large static fields, discarded sockets, file handles, threads, JDBC connection which you don't need.

The File.deleteOnExit on exit must use some memory to be able to perform its task. This is not a leak in my option as it is not retaining memory which is not needed.

Having static fields and threads which you don't need will waste memory and this is bug which the JVM cannot correct for.

However, creating sockets, file handles, and JDBC connections the JVM does handle. When the finalize() method is called, these resources are cleaned up.

Conclusion

In Java it is meaningful to refer to objects which are retained and are not longer needed as a "memory leak".

There is nothing in the Java language which is prone to this problem and the JRE libraries do protect themselves from bugs in application code.

Your application can still have a memory leak, and you need to make sensible choices about when you still need a resource, in particular a thread and if you hold onto it too long it can mean you have a "memory leak".

 

From http://vanillajava.blogspot.com/2011/07/java-and-memory-leaks.html

Memory (storage engine) Java (programming language)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Multi-Tenant Architecture for a SaaS Application on AWS
  • Integrate AWS Secrets Manager in Spring Boot Application
  • Create CloudWatch Custom Log Metric Alarm Notification Email Solution Using Terraform
  • 10 Most Popular Frameworks for Building RESTful APIs

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: