Is there any way static block is executed more than once? if so then how?

My Understanding Static block is executed during class loading, If a class is already loaded then there is no way to load the class other than class reloading

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

My Understanding In Class Loading JVM loads bytecode of the Java file, so it can not keep all thousands classes bytecode in memory, so it might be discarding the rarely used code and reloading it again when it is necessary and during reload JVM is not initializing static variables and bloc开发者_JAVA百科ks again(may be using some tracking mechanism)

Doubt/Question

2) If my above understanding is incorrect then please correct me

To my knowledge the JVM will never reload a class per se; once a class is loaded it stays loaded forever. Class definitions are held in the "PermGen" memory pool for this reason.

However, it is possible for your class' bytecode to be loaded by multiple classloaders, and each time this happens the static block will be executed again as this is a new class. Each class is only visible within the scope of its own classloader, whereas typically any classloader can see your bytecode if it's on the classpath, so this is a possible (if undesirable) situation.

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

A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector as discussed in §12.6.

Then, if the class needs using again, it will obviously be loaded again. And in fact, several classloaders can load the same class separately, in parallell.

Static block is executed ONE AND ONLY ONCE per classloader when the class is gets loaded. The sequence of static block execution as per its occurance, see the sample code below and its output. Static code is at class level and not at instance level per ClassLoader instantiating this class. Note: For brevity, I had not invoked 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[]){

}

}

output of program:-

hello...1

hello...2

I you explicitly use a new ClassLoader to load the class again, the static block for this class will be executed again.

The Java Language Specification speaks of the mechanism of loading, unloading, and reloading of classes in great details.

JLS 12.2 Loading of Classes and Interfaces

Loading refers to the process of finding the binary form of a class or interface type with a particular name, perhaps by computing it on the fly, but more typically by retrieving a binary representation previously computed from source code by a compiler, and constructing, from that binary form, a Class object to represent the class or interface.

The precise semantics of loading are given in chapter 5 of The Java Virtual Machine Specification (whenever we refer to the Java virtual machine specification in this book, we mean the second edition, as amended by JSR 924). Here we present an overview of the process from the viewpoint of the Java programming language.

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

Under certain circumstances, it is possible to unload classes and interfaces, which may cause an unpreventable reload.

12.7 Unloading of Classes and Interfaces

An implementation of the Java programming language may unload classes. A class or interface may be unloaded if and only if its defining class loader may be reclaimed by the garbage collector as discussed in §12.6. Classes and interfaces loaded by the bootstrap loader may not be unloaded.

Class unloading is an optimization that helps reduce memory use. Obviously, the semantics of a program should not depend on whether and how a system chooses to implement an optimization such as class unloading. To do otherwise would compromise the portability of programs. Consequently, whether a class or interface has been unloaded or not should be transparent to a program.

However, if a class or interface C was unloaded while its defining loader was potentially reachable, then C might be reloaded. One could never ensure that this would not happen.

In fact, it went to address your specific concerns:

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

• Static variables (whose state would be lost).
• Static initializers (which may have side effects).
• Native methods (which may retain static state).

Furthermore the hash value of the Class object is dependent on its identity. Therefore it is, in general, impossible to reload a class or interface in a completely transparent manner.

Since we can never guarantee that unloading a class or interface whose loader is potentially reachable will not cause reloading, and reloading is never transparent, but unloading must be transparent, it follows that one must not unload a class or interface while its loader is potentially reachable. A similar line of reasoning can be used to deduce that classes and interfaces loaded by the bootstrap loader can never be unloaded.

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

Class unloading is an optimization that is only significant for applications that load large numbers of classes and that stop using most of those classes after some time. A prime example of such an application is a web browser, but there are others. A characteristic of such applications is that they manage classes through explicit use of class loaders. As a result, the policy outlined above works well for them.

Strictly speaking, it is not essential that the issue of class unloading be discussed by this specification, as class unloading is merely an optimization. However, the issue is very subtle, and so it is mentioned here by way of clarification.

Andrzej Doyle answered your specific question. However:

My Understanding Static block is executed during class loading

To be clear, loading and initialization are distinct phases; a class can be loaded without being initialized. The Java Virtual Machine Specification specifies the three conditions that will cause a class to be initialized: an instance is created, a static method is invoked, or a non-constant static field is used or assigned.