Is there a static block method that runs more than once? if so, how?

Question

My understanding is that a static block is executed during class loading. If the class is already loaded, then there is no way to load the class other than reloading the class.

Doubt / Question 1) Is there a time when the JVM reloads the class?

My understanding In the Download class, the JVM loads the bytecode of the Java file, so it cannot store all the thousands of bytecode classes in memory, so it can discard rarely used code and reload it again when necessary, and the JVM does not initialize during reboot static variables and blocks (maybe some kind of tracking mechanism is used)

Doubt / Question
2) If my above understanding is wrong, please correct me.

Answer 1

As far as I know, the JVM will never reload the class as such; once the class is loaded, it remains loaded forever. For this reason, class definitions are stored in the PermGen memory pool.

However, it is possible that the bytecode of your class is loaded by several class loaders, and each time this happens, the static block will be executed again, since this is a new class. Each class is visible only within its own class loader, while usually any class loader can see your bytecode if it is in the class path, so this is possible (if this is not desirable).

Answer 2

Classes can be unloaded if ClassLoader loading becomes unavailable: https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.7

A class or interface can be unloaded if and only if its defining class loader can be recovered by the garbage collector, as described in section 12.6.

Then, if the class needs to be reused, it will obviously be loaded again. And in fact, multiple class loaders can load the same class separately, in parallel.

Answer 3

The static block is executed ONLY AND ONLY ONCE for the class loader when loading the class. The sequence of execution of a static block depending on its availability, see the code example below and its output. The static code is at the class level, not at the instance level for the ClassLoader class that instantiates this class. Note. For brevity, I did not call the method and its output here.

public class StaticTest {

  // 1st Static block invoked first. static{ System.out.println("hello...1"); } // 2nd Static block, invoked after 1st static block above. static{ System.out.println("hello...2"); } public static void Staticmeth() { System.out.println("hello...3"); } public static void main(String ag[]){ } 

}

program output: -

hi ... 1

hi ... 2

Answer 4

I am again using the new ClassLoader to ClassLoader class, the static block for this class will be executed again.

Answer 5

The Java language specification speaks of a mechanism for loading, unloading, and reloading classes in detail.

JLS 12.2 Loading Classes and Interfaces

Downloading refers to the process of finding a binary form of type class or interface with a specific name, possibly by calculating it on the fly, but usually by obtaining a binary representation previously computed from the source code, the compiler and building a class object from this binary form to represent class or interface.

The exact semantics of loading are given in Chapter 5, Java Virtual Machine Specifications (whenever we refer to the Java Virtual Machine specification in this book, we mean the second edition as amended by JSR 924). Here we provide an overview of the process in terms of the Java programming language.

The binary format of a class or interface is usually the class file format described in the Java Virtual Machine Specification above, but other formats are possible provided that they meet the requirements specified in §13.1. The defineClass of class ClassLoader can be used to build class objects from binary representations in the class file format.

In certain circumstances, you can unload classes and interfaces, which can cause an unpredictable reboot.

12.7 Unloading classes and interfaces

An implementation of the Java programming language can unload classes. A class or interface can be unloaded if and only if its defining class loader can be returned by the garbage collector, as described in section 12.6. Classes and interfaces loaded by the boot loader cannot be unloaded.

Class offloading is an optimization that helps reduce memory usage. Obviously, the semantics of the program should not depend on how and how the system decides to implement optimization, such as class unloading. . Otherwise, it may jeopardize portability of the programs. Therefore, regardless of whether the class or interface was unloaded or not, it should be transparent to the program.

However, if a class or C interface was unloaded, while its defining loader was potentially available, C could be reloaded. It can never be guaranteed that this will not happen.

In fact, he went to your specific problems:

Rebooting may not be transparent if, for example, the class has:

• Static variables (whose state will be lost).
• Static initializers (which may have side effects).
• Native methods (which can maintain a static state).

In addition, the hash value of a class object depends on its identity. Therefore, as a rule, it is not possible to completely reload a class or interface.

Since we can never guarantee that unloading a class or interface whose loader is potentially available will not result in a reboot, and reloading will never be transparent, but unloading must be transparent, it follows that you cannot unload a class or interface while its loader potentially achievable. A similar line of reasoning can be used to deduce that classes and interfaces loaded by the boot loader can never be unloaded.

It should also be argued why it is safe to unload class C if its defining class loader can be restored. If the defining loader can be restored, then there can never be any live links to it (this includes links that are not live, but can be resurrected by finalizers). This, in turn, can be true only if there can never be any live links to any of the classes defined by this loader, including C, either from their instances or from the code.

Class unloading is an optimization that is important only for applications that load a large number of classes and which stop using most of these classes after a while. A striking example of such an application is a web browser, but there are others. A characteristic feature of such applications is that they manage classes through the explicit use of class loaders. As a result, the policies outlined above work well for them.

Strictly speaking, it is not important that the problem of class unloading is discussed by this specification, since class unloading is just an optimization. However, the question is very subtle, and therefore it is mentioned here by way of clarification.

Answer 6

Andrzej Doyle answered your specific question. But:

My understanding is Static block is executed when loading classes

To be clear, loading and initialization are different phases; a class can be loaded without initialization. The Java virtual machine specification defines three conditions that will cause the class to be initialized: an instance is created, a static method is called, or a non-constant static field is used or assigned.