Java program running analysis

Tool used: Eclipse Stardard 4.32 (window7 environment)

Today, we use a simple example to analyze how a java program runs on us. Some content is for reference to others and will be noted in the reference area.

My test code is as follows:

Public class Test { Public static void main (String [] args ){ New Test (); Int test = 1; // only for testing convenience, remove the IO Analysis } }

It is such a simple code that how to run on our machines is really a tough thing.

First, let's take a look at how Eclipse is started.

Reference books: Java programming ideology (version 4) deep understanding of Java Virtual Machine (by Zhou Zhiming)

Here I will not repeat the detailed principles, because that is not what I want to talk about. What I want to analyze is how the simplest java program runs.

Instead of how an exe runs.

Step 1:

We will double-click the eclipse.exe program and the launch page will appear. This process reads the configuration file eclipse. ini in the same directory and retrieves some parameters that eclipse needs to run, For example, where is the jdk/jre path we installed? Before jdk, we will find the-vm parameter in eclipse. ini, but after This parameter is not available for later versions, because later versions of java programs do not necessarily run in sun's hotspot virtual machine, or Run other VMS. Therefore, this parameter is removed in later versions, and the jar package startup. jar that starts the eclipse program will be read. We decompress \ plugins \ org. eclipse. equinox. launcher_1.3.0.v20130327-1440.jar (Different Versions later Parameters will be different.) The Main class to be started will be found, and then the static method Main (String args) of the main class will call a series Column parameters related to the local machine. Call the local method through the JNI interface to start Eclipse. If you are interested, you can read The four reference blogs described in detail.

Step 2:

We will run the code we compiled. Although we only click a run button in Eclipse, Eclipse is

Call the tool we installed in the local jdk/bin to start our JVM, and load our class to the memory.

So what we need to analyze is this step. How can we write the java code and run it?

What we can do is to debug and track the source code to analyze what the JVM has encapsulated.

Step 3:

Okay. Let's get started.

We set the breakpoint at new Test () and right-click it to run in debug mode. The following figure is displayed:

We can see in the upper left corner that we run the Test program on port 56056 on the local machine and run the main thread in the main method. This also proves that, the main function we wrote is the main thread of the entire Program. At the same time, Eclipse calls the function and installs it in "C: \ Program Files \ Java \ jre7 \ bin \ javaw.exe"

If we are in the above path at this time, such as the marked place:

We will find some of our JVM parameter information, such:

Command Line is part of the JVM parameter we started. If you need detailed parameters, you can use jconsole.exe in jdk/binto call up the JVM system analysis tool. Run the tool as follows:

By the way, we can see that we have started three steps, one is jlele.exe itself, the other is Eclipse itself, and the third is the Test class compiled by ourselves. Here we choose Test to connect and enter the Test class. Then we can find an analysis console, click to enter the VM overview to find more JVM parameters ,:

We can see that the parameters in the Command Line opened in the Eclipse attribute are only part of the data at the bottom. we don't pay attention to these things for the moment. We just want to analyze how our program runs.

Continue back to Eclipse. We debug our program step by step to see how our program enters the memory.

We can see from the figure above that the init () method is called in Test (), but we didn't write this method clearly. We noticed that init was wrapped up by <>, in fact, this is called by JVM. The whole method is called when a class is instantiated. the Java compiler will generate at least one instance initialization method for each of its classes. In the Class file, it is called" "For details, refer to the in-depth understanding of Java Virtual Machine book. After the above test, we found that when we bypass the IO part, the program will soon exit the thread, so for more details, I added the IO part, so the code part is changed:

Demo. java Package com. test; Public class Demo { Public void say (){ SayHello (); } Private void sayHello (){ System. out. println ("hello "); } } Test. java Package com. test; Public class Test { Public static void main (String [] args ){ Demo demo = new Demo (); Demo. say (); } }

In this way, we can analyze this situation a little more complicated. After entering the debug mode, we will find that the situation is different.

During the initialization of our Test class, a ClassNotFoundException exception prompt will appear. In fact, this is a verification phase when the JVM loads our class. For security, JVM has done a lot of verification to ensure that the class files we write must be legal. the existence of this class is one of the factors. When the JVM finds that the class we write exists, it will go to the instance to talk about it, but before that, JVM still needs to make some preparations to initialize its parent class or interface, which is to ensure the integrity of the data of this class, because in the dependency inversion principle, we recommend that each class have its own class or interface as much as possible, and JVM agrees with this, but does the class we write show that it inherits from a class, it will inherit the Object class by default. Therefore, the JVM will naturally initialize our Object class next. After the JVM passes a series of class file verification, to load the class files we have written through different class loaders.

We can see that different loaders finally arrive at our class loaders in Eclipse, and finally the class loaders that can load the classes we have compiled

Download.