Java Memory Management (Maaike van Putten, Seán Kennedy) (Z-Library)

📄 File Format: PDF

💾 File Size: 11.5 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

(This page has no text content)

📄 Page 2

(This page has no text content)

📄 Page 3

Table of Contents Preface Chapter 1: Different Parts of the Java Memory Chapter 2: Primitives and Objects in Java Memory Chapter 3: Zooming in on the Heap Space Chapter 4: Freeing Memory with Garbage Collection Chapter 5: Zooming in on the Metaspace Chapter 6: Configuring and Monitoring the Memory Management of the JVM Chapter 7: Avoiding Memory Leaks Index Other Books You May Enjoy

📄 Page 4

Preface Understanding how Java memory works can be of great benefit to your Java coding and application management. It makes it easier to visualize what is going on with object composition and what happens with object allocation and deallocation, combined with object composition. As you are probably aware, object composition is where objects contain other objects. For example, a Person class specifies a property of type Address, which also happens to be a class. Knowing how this all works in memory makes it easier to know what steps to take to get to a certain data field. Also, the concept of static and accessing the instance using the this keyword will be so much easier to visualize and understand completely when you understand how the memory of Java works. Without understanding how Java memory works, it is impossible to truly grasp the concepts of static and this. Another advantage of understanding Java memory well is that the difference between using a primitive or a class reference as an argument makes a lot more sense all of a sudden. This also helps with understanding the immutability and mutability of objects. More complex topics will make more sense too, such as concurrency, one of my personal favorites. This is when multiple things are happening at the same time in your application (multithreading). It’s possible that you haven’t worked with it yet, but as a Java developer, you’ll have to one day. Understanding Java memory makes it easier to understand certain aspects of concurrency, especially data access. Another complex topic that will be easier to understand is garbage collection. This is of crucial importance for performance since it’s a very expensive process, and you want to need it as little as possible and optimize it as much as possible. Everything that you are probably using on a daily basis already will become clearer when you understand better how Java memory works.

📄 Page 5

Who this book is for This book is for all sorts of Java professionals. It doesn’t really matter whether you’re a junior or senior developer, a DevOps engineer, a tester, or the system admin of a Java application. If you currently do not have an in- depth knowledge of Java memory, garbage collection, and/or JVM tuning, this book will help you to take your Java skills to the next level.

📄 Page 6

What this book covers Chapter 1, Different Parts of Java Memory, covers the different parts of Java memory: the stack, the heap, and the Metaspace. We’ll start with the stack memory and how variables are stored on the stack. We’ll then move on to deal with objects and how these are stored on the heap. Next, we’ll briefly discuss accessing primitives and objects. Finally, we’ll describe the Metaspace and what it’s used for. Chapter 2, Primitives and Objects in Java Memory, zooms in on primitives and objects in Java memory. We’ll be dealing with the heap and stack in more detail here. With the use of visualization, we’ll show what happens during the execution of a Java program with the stack and the heap memory. Once the basics of memory management are clear, we’ll deal with object references in more detail. We explain how Java’s call-by-value mechanism, when applied to references, can lead to a security issue known as escaping references. We discuss how to solve this issue. Chapter 3, Zooming in on the Heap Space, focuses on the different parts of the heap space. It has two main areas: the young generation space and the tenured space. The young generation space contains two separate areas: the eden space and the survivor space. We won’t dive into the garbage collection process in this chapter, but we’ll briefly mention it and what it is to explain how objects are promoted between spaces. Visualization of the heap and the different areas will be added to provide clarity regarding the heap space’s details. The content of this chapter is necessary to understand the garbage collection algorithms that will be discussed in the next chapter. Chapter 4, Freeing the Memory with Garbage Collection, dives into the deallocation of the objects on the heap. Deallocation of the memory is necessary in order for an application to keep running. Without the ability to free memory, we could allocate it only once and eventually we’d run out of memory. In this chapter, we are dealing with when objects on the heap space are eligible for garbage collection and what phases the garbage collector goes through. We’ll end with a discussion on the different implementations of the garbage collector. We’ll make this as visual as possible to increase understanding.

📄 Page 7

Chapter 5, Zooming in on the Metaspace, touches upon the Metaspace, which is used by the JVM for class metadata and for example static variables. This metadata gets stored when the classes are loaded. We’ll describe the class loading process and how memory is allocated. The releasing of Metaspace memory is a bit different from the releasing of heap memory. This process will be described here as well. Chapter 6, Configuring and Monitoring the Memory Management of the JVM, explains how to get started with JVM tuning. First, we’ll describe what JVM tuning is and who needs it. There are several metrics that are relevant for the tuning of the JVM when it comes to memory management. We’ll examine these metrics and how to obtain them. We’ll end with the actual tuning and adjusting of the configuration of the JVM and how to use profiling to get insights into the effects of the tuning. Chapter 7, Avoiding Memory Leaks, deals with how to use the memory well and how to spot and solve memory leaks. Whenever objects are held in memory that are no longer needed, we get memory leaks. In the beginning, this can seem harmless, but over time it will slow down an application and the application will require a restart in order to function properly again. In this chapter, we’re going to make sure that the reader understands memory leaks and knows how to spot them. We’ll end with very common mistakes that lead to memory leaks and how to avoid them. To get the most out of this book This book assumes Java 8 or later. A particular operating system or IDE is not mandatory. If you plan to run the examples yourself, then VisualVM, the visual tool for monitoring Java applications in memory, would be useful. If you currently have nothing installed on your system, the following setup will suffice: JDK 8 or later (Oracle’s JDK or OpenJDK) IntelliJ IDEA(community edition is good enough) or Eclipse

📄 Page 8

Software/hardware covered in the book Operating system requirements Java 8+ Windows, macOS, or Linux If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code. Download the example code files You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/B18762_Java-Memory-Management. If there’s an update to the code, it will be updated in the GitHub repository. We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out! Download the color images We also provide a PDF file that has color images of the screenshots and diagrams used in this book. You can download it here: https://packt.link/OeQqF. Conventions used There are a number of text conventions used throughout this book. Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “For example, int x; defines (creates) a primitive variable x which is of (the primitive) type int.” VisualVM

📄 Page 9

A block of code is set as follows: Object o = new Object(); System.out.println(o); o = null; When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold: Object o = new Object(); System.out.println(o); o = null; Any command-line input or output is written as follows: java.lang.Object@4617c264 Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “There is a Create another option beside the Create button.” Tips or important notes Appear like this. Get in touch Feedback from our readers is always welcome.

📄 Page 10

General feedback: If you have questions about any aspect of this book, email us at customercare@packtpub.com and mention the book title in the subject of your message. Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form. Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at copyright@packt.com with a link to the material. If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com. Share Your Thoughts Once you’ve read Java Memory Management, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback. Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content. Download a Free PDF copy of this book Thanks for purchasing this book! Do you like to read on the go but are unable to carry your print books everywhere?

📄 Page 11

Is your eBook purchase not compatible with the device of your choice? Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost. Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application. The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily Follow these simple steps to get the benefits: 1. Scan the QR code or visit the link below https://packt.link/free-ebook/9781801812856 2. Submit your proof of purchase 3. That’s it! We’ll send your free PDF and other benefits to your email directly

📄 Page 12

Different Parts of the Java Memory Do you know the phenomenon of having to restart an application to boost the performance of that application? If so, you may have experienced the outcome of poor memory management: the memory getting full and the application slowing down. This is not always why applications slow down – other causes such as processing data from a server or a bottleneck in the network, among other things, play a role – but memory management problems are a usual suspect of degrading application performance. You’ve probably heard of memory in the field of computer science before. That makes sense because computers have memory and they use this memory to store and access data while running programs (which in their turn are data too!). So, when does an application use memory? Well, for example, let’s say you’d like to run an application that is going to process a huge video file. If you do this with your activity monitoring application (for example, Activity Monitor on macOS or Task Manager on Windows) open, you’ll see that the used memory increases once you open the application and load the video. Memory is a finite resource on your computer and once your computer runs out of it, it becomes slow. There are many ways to improve the performance of an application. A deeper understanding of how exactly this memory works is one of the ways that could help you improve the performance of your applications. Memory that is used efficiently by using good practices in coding is going to boost the performance of your application. So, coding well and being mindful of how the memory works should always be the first way to achieve high performance when it comes to memory management. There is another way in which Java memory management can be influenced and that is by configuring the Java Virtual Machine (JVM), which takes care of the Java memory. This is something that we’ll cover in Chapter 6 when we’re ready for it.

📄 Page 13

The efficient handling of Java memory is of crucial importance for the performance of a Java application. In Java, this is especially the case because it comes with expensive processes such as garbage collection, which again, we’ll see later after gaining enough basic knowledge to comprehend it. Memory management is also important for data integrity in a concurrent context. Don’t worry if this sounds very complicated at the moment. By the end of this book, you’ll understand what is meant by this. So, to optimize the usage of our application’s Java memory, we’ll first need to understand what this memory looks like and gain knowledge of the basic processes with the memory. In this chapter, we’ll do just that. We’re going to explore the different parts of Java memory and how we use this in our day-to-day coding. You’ll get a good overview of Java memory and you’ll be ready for the deep dive that’s coming in the next chapters. In order to do so, we’ll cover the following topics: Technical requirements The code for this chapter can be found on GitHub at PacktPublishing/B18762_Java-Memory-Management. Understanding computer memory and Java memory Understanding computer memory and Java memory Creating variables in Java Storing variables on the stack Creating objects in Java Storing objects on the heap Exploring the Metaspace

📄 Page 14

First things first – running applications, Java or not, requires computer memory. The application’s memory is the physical memory of the computer. Having more knowledge about the memory of the computer is going to help in our understanding of Java memory. Therefore, let’s discuss the concept of memory and Java memory in a bit more detail. Computer memory Chances are that you already know this, but just to reiterate: a computer has memory. This is the part of the computer that is used for storing information that is used for executing processes. We also call this the main memory or sometimes primary storage. An important point to make here is that this is different from computer storage, where long-term information is stored. This storage is long-term because the HDD storage stores the information magnetically and the SDD can be qualified as Electrically Erasable Programmable Read-Only Memory (EEPROM). They don’t need constant power to persist the data. On the other hand, one common type of main memory, Random Access Memory (RAM), needs constant electricity power to persist data. This can be compared to our human brains, at least partially. We have long- term and short-term memory. We use our long-term memory for our, well, memories – for example, a cherished childhood memory of your father pushing you around playfully in a wheelbarrow while your mother quoted from your most beloved storybook while you were wearing your favorite outfit that you had as a 3-year-old (magical, let’s save the rest for my memoir or therapist). Then there’s short-term memory, which is great when you want to remember the six digits for a two-step verification process and even better if you can’t recall them a few minutes later. Accessing the main memory The computer, or actually the CPU of the computer, can access the main memory much faster than it can access the permanent storage space. In the main memory, programs are currently open and the data that they’re using is being stored.

📄 Page 15

Maybe you can recall starting your computer and opening an app you use daily for the first time that day and realizing that it takes a few seconds to boot. If you close it, perhaps accidentally, and open it again right after closing it, it is a lot faster. The main memory works as some sort of cache or buffer, and this explains the phenomenon of the shorter load time the second time. The second time, it can open it from the main memory instead of from the storage, which proves, or at least supports, the point that the main memory is faster. The great news is that you don’t need to understand the tiniest details of the computer memory, but a rough overview will help. Overview of the main memory The most common part of the main memory is the RAM. The RAM is a huge part of what determines the performance of a computer. Running or active applications need RAM for storing and accessing data. This memory can be accessed very quickly by the applications and processes. If there is enough RAM available and if the Operating System (OS) does a great job of managing the RAM, your applications will reach their performance potential. You can see how much RAM is available by having a look at your monitoring app. For me, that is Activity Monitor. As you can see in the following figure, my computer is using quite a bit of memory at the moment:

📄 Page 16

Figure 1.1 – Screenshot of Activity Monitor on macOS 12.5 I have sorted the processes from high memory to low. At the bottom, you can see a summary of the available memory and the memory used. To be honest, this seems a little high and I should probably investigate it after writing this chapter. Why should I investigate this if I still have a lot of memory available? Well, if the RAM gets too full, the applications that are running can only do so very slowly. This is something you’re likely to have experienced already when you've run more or heavier applications than your computer specifications allowed. The RAM is volatile. This means that when you turn off the power, the information is gone. The main memory does not only consist of RAM. The Read-Only Memory (ROM) is part of the main memory too, but it’s non-

📄 Page 17

volatile. It contains instructions that the computer needs to start, so luckily this does not disappear when we turn the power off! Fun fact We refer to the main memory as RAM, which is very common terminology, but now you know it’s technically incorrect! A fun fact indeed. Java memory and the JVM You may wonder if we are still going to cover Java memory – and yes, we are! The Java memory is somewhat similar to, but also different from, the computer’s memory model. However, before we talk about Java memory, I’ll need to explain what the JVM is. I really appreciate your patience, I must say. The JVM The JVM executes Java applications. Does that mean that the JVM understands Java? No, not at all! It understands bytecode – the .class files. This means the compiled Java programs. The code of some other languages, such as Kotlin, is compiled to JVM bytecode as well and can therefore be interpreted by the JVM. This is why they’re sometimes referred to as JVM languages, such as Java, Kotlin, and Scala, among others. The steps can be seen in Figure 1.2:

📄 Page 18

Figure 1.2 – Write once, run anywhere

📄 Page 19

The source code (in the figure, we assume this is Java source code) is being compiled by the Java compiler. The result is .class files containing bytecode. This bytecode can be interpreted by the JVM. Every platform, whether macOS, Windows, or Linux, has its own version of the JVM to execute the bytecode. This means that the application doesn’t need to be modified to run on different environments because the platform-specific JVM takes care of that. The JVM is actually why Java once was famous and beloved for its write once, run anywhere principle. The reason Java is not so famous for this anymore is that it’s sort of normal for languages to work this way nowadays. Any platform with a JVM installed on it could run Java since the JVM takes care of translating it to the machine it’s running on. I typically compare this to a travel plug adapter. Plugs don’t fit globally because different regions use different sockets. You can use your own adapter wherever you are when you have the right travel adapter plug with you. In this case, the travel adapter would be the JVM. The “wherever you are” would be the platform you’re trying to run Java on and your adapter would be your Java program. Let’s see the basics of how the JVM deals with memory management. Memory management and the JVM The Java memory stores the data that is required to run Java applications. All the instances of classes that live in a Java application are stored in the Java memory. This is also true for primitive values. What about constants? Also stored in the Java memory! And what about the method codes, native methods, field data, method data, and the order in which methods are being executed? You can probably guess that they are all stored in Java memory! One of the tasks of the JVM is managing the Java memory. Without this memory management, no memory could be allocated and objects couldn’t be stored. Even if that part was in place, it would never be cleaned up. So, cleaning up the memory, which is also called the deallocation of objects, is of great importance for running Java code. Without it, the code can’t run, or

📄 Page 20

if it’s only allocated, it will get full and the program will run out of memory. How exactly this works is something will learn in Chapter 4 when we discuss the deallocation process – called garbage collection. Long story short: memory management is important. It is one of the very important tasks of the JVM. Actually, nowadays, we sort of take automatic memory management for granted, but in its early days, this was very new and special. Let’s have a look at what could happen if the JVM was not managing the memory for us. Memory management before Java In older languages, such as C and C++, memory management was the responsibility of the developer. This meant that allocation and deallocation of a memory area had to be done using a command. For example, in C, the following code snippet shows how you could allocate some memory and assign a value to it. Please note that this is just a small example to illustrate how awesome automatic garbage collection is and in no way a complete guide to how to do memory allocation in C – there’s a lot more to it: int* x; x = (int*)malloc(4 * sizeof(int)); int* means that x holds the value of the pointer to the base address of the memory block. malloc, which stands for memory allocation, is a function that is used to allocate a block of memory with a specified size. In this case, that specified size is four times the size of int. The function returns the base address. If we would then like to assign a value to the memory allocation, we need to do this by using *x – otherwise, we will be overriding the location: *x = 5;