Object lifecycle

Hi! I think you wouldn't be very surprised if I told you that your computer has a limited amount of memory :) Even your hard drive (which is many, many times the size of RAM) can get chock full of your favorite games, TV shows, and other things. To prevent this from happening, you need to monitor the current state of your computer's memory and delete unnecessary files. How does all this relate to Java programming? Quite directly! After all, creating any object causes the Java machine to allocate memory for it. A large real-world program creates tens or hundreds of thousands of objects, and a chunk of memory is allocated for each of them. But what do you think, how many of these objects exist? Are they "alive" all the while our program is running? Of course not. Even with all their advantages, Java objects are not immortal :) Objects have their own lifecycle. Today we'll take a little break from writing code and explore this process :) It's also very important for understanding how a program works and for managing resources. So, where does an object's life begin? Like a human, from birth, i.e. when it is created.

Cat cat = new Cat();// Our Cat object's lifecycle begins now!

First, the Java virtual machine allocates the memory necessary to create the object. Then it creates a reference to it (in our case, cat) to make it possible to keep track of it. Then all the variables are initialized, the constructor is called, and our fresh object is now living its own life :) Object lifetimes vary. There are no exact figures here. In any event, an object lives in the program and performs its functions for some period of time. To be precise, the object is "alive" as long as there are references to it. As soon as there are no references, the object "dies". For example:

public class Car {
  
   String model;

   public Car(String model) {
       this.model = model;
   }

   public static void main(String[] args) {
       Car lamborghini  = new Car("Lamborghini Diablo");
       lamborghini = null;

   }

}

In the main() method, the "Lamborghini Diablo" Car object ceases to be alive on the second line. There was only one reference to it, and the reference was set to null. Since there are no remaining references to the Diablo, it becomes "garbage". A reference doesn't have to be set to zero for this to happen:

public class Car {

   String model;

   public Car(String model) {
       this.model = model;
   }

   public static void main(String[] args) {
       Car lamborghini  = new Car("Lamborghini Diablo");

       Car lamborghiniGallardo = new Car("Lamborghini Gallardo");
       lamborghini = lamborghiniGallardo;
   }

}

Here we've created a second object and assign it to the lamborghini reference. Now two references point to the Lamborghini Gallardo object, but the Lamborghini Diablo object has none. This means the Diablo object becomes garbage. This is when Java's built-in garbage collector (GC) kicks in. The garbage collector is an internal Java mechanism responsible for freeing up memory, i.e. removing unnecessary objects from memory. There's a reason why we chose to represent it with a robot vacuum cleaner. The garbage collector works in about the same way: it "moves about" your program in the background, collecting garbage. You practically don't have to interact with it. Its job is to delete objects that are no longer used in the program. Thus, it frees up memory for other objects. Do you remember that at the beginning of the lesson we said in real life you have to monitor your computer's state and delete old files? If we're talking about Java objects, the garbage collector does this for you. The garbage collector is started many times as your program runs: you don't have to explicitly call it and give it commands (though this is technically possible). We'll talk more about the garbage collector later and analyze how it works in more detail. When the garbage collector reaches an object—just before it is destroyed—the object's special finalize() method is called. This method can be invoked to release certain additional resources used by the object. The finalize() method belongs to the Object class. In other words, it's similar to equals(), hashCode() and toString() (which you've previously met). Every object has it. It differs from other methods in that...how should we say this...it's very willful. By that we mean that it is not always called before an object is destroyed. Programming is a very precise activity. The programmer tells the computer to do something, and the computer does it. I assume you've become accustomed to this sort of behavior, so at first it may be difficult for you to accept the following idea: "Before an object is destroyed, the Object class's finalize() method is called. Or not. If we get lucky!" Still, this is reality. The Java machine itself determines whether to call finalize() on a case by case basis. As an experiment, let's try running the following code:

public class Cat {

   private String name;

   public Cat(String name) {
       this.name = name;
   }

   public Cat() {
   }

   public static void main(String[] args) throws Throwable {

       for (int i = 0 ; i < 1000000; i++) {

           Cat cat = new Cat();
           cat = null;// The first object becomes available for garbage collection here
       }
   }

   @Override
   protected void finalize() throws Throwable {
       System.out.println("The Cat is destroyed!");
   }
}

We create a Cat object, and in the next line we zero out the only reference to it. And we do that a million times. We've explicitly overridden the finalize() method. Each time a Cat object is destroyed, it must display a string—a total of one million times. But no! To be exact, on my computer it was executed only 37346 times! In other words, my Java machine decided to call the finalize() method in only 1 out of every 27 cases. In the other cases, garbage collection didn't involve this call. Try running this code yourself. You will most likely get a different result. As you can see, it's hard to call finalize() a reliable partner :) So, here's a small tip for the future: don't rely on the finalize() method to release critical resources. The JVM might call it, or it might not. Who knows? If your object held some performance-critical resources (for example, an open database connection) while it was alive, it would be better to create and explicitly call a special method to release them when the object is no longer needed. That way, you'll know for sure that your program's performance won't suffer. We started by saying that working with memory and garbage collection are very important topics, and indeed they are. Mishandling resources and misunderstanding how unnecessary objects are cleaned up can lead to one of the most unpleasant bugs: memory leaks. This is one of the most well-known programming errors. It even has its own Wikipedia article. Poorly written code can create a situation where memory is allocated every time for newly created objects, but old, unnecessary objects are unavailable for garbage collection. Since we've already made robot vacuum cleaner analogy, imagine what would happen if before running the robot you scattered socks all over the house, smashed a glass vase, and left Lego pieces all over the floor. Naturally, the robot would try to do something, but one day it will seize up. For the vacuum cleaner to run properly, you need to keep the floor in decent shape and pick up everything that it can't handle. The garbage collector follows the same principle. If a program has a lot of objects that it can't clean up (like a sock or Lego for our robotic vacuum cleaner), one day we'll run out of memory. Not only will your program hang, all the other programs that happen to be running on the computer will too. After all, they won't have enough memory either (returning to our analogy, the broken glass on the floor stops not only the vacuum cleaner, but also the people who live in the home). In short, this is what object lifecycle and garbage collection look like in Java. You don't need to memorize this: it's enough to simply understand how it works. In the next lesson, we'll return to these processes in more detail. But for now, you can return to solving CodeGym tasks :) Good luck!