Java: some learning note for Java calssloader and Servlet

1. Java Classloader

链接: https://en.wikipedia.org/wiki/Java_Classloader

摘要：

The Java Classloader is a part of the JRE that dynamically loads Java classes into the JVM. Usually only loaded on demand.

In Java, libraries are typically packaged in JAR files. The most important type of object contained in a Jar file is a Java class. A class can be thought of as a named unit of code. The class loader is responsible for locating libraries, reading their contents, and loading the classes contained within the libraries. A class with a given name can only be loaded once by a given classloader.

When the JVM is started, three class loaders are used:

1. Bootstrap class loader
2. Extensions class loader
3. System class loader

The bootstrap class loader loads the core Java libraries located in the <JAVA_HOME>/jre/lib directory. This class loader, which is part of the core JVM, is written in native code.

The extensions class loader loads the code in the extensions directories (<JAVA_HOME>/jre/lib/ext,or any other directory specified by the java.ext.dirs system property).Implemented by the sun.misc.Launcher$ExtClassLoader.

The system class loader loads code found on java.class.path, which maps to the CLASSPATH environment variable. This is implemented by the sun.misc.Launcher$AppClassLoader class.

User defined calss loader:

　　Every Java class loader has a parent class loader, defined when a new class loader is instantiated or set to the virtual machine's system default class loader.

　　This makes it possible (for example):

• to load or unload classes at runtime (for example even from an HTTP resource). This is an important feature for (for example):
  • implementing scripting languages, such as Jython
  • using bean builders
  • allowing multiple namespaces to communicate. This is one of the foundations of CORBA / RMI protocols for example.

Java EE application servers typically load classes from a deployed WAR or EAR archive by a tree of classloaders, isolating the application from other applications, but sharing classes between deployed modules. So-called "servlet containers" are typically implemented in terms of multiple classloaders.

摘要 releate to WAR from https://en.wikipedia.org/wiki/WAR_(file_format):

　　The /WEB-INF/classes directory is on the ClassLoader's classpath. (The classpath consists of a list of locations from which .class files can be loaded and executed by the JVM.) The /WEB-INF/classes directory contains the classes 　　

　　associated with the web application itself.

　　Any JAR files placed in the /WEB-INF/lib directory will also be placed on the ClassLoader's classpath.

2. Java Servlet

链接： https://en.wikipedia.org/wiki/Java_servlet

摘要：

 Compared with other web application models （namely CGI）

Traditional CGI scripts written in Java have a number of performance disadvantages:

• When an HTTP request is made, a new process is created each time the CGI script is called. The overhead associated with process creation can dominate the workload especially when the script does relatively fast operations. Thus, process creation will take more time for CGI script execution. In contrast, for servlets, each request is handled by a separate Java thread within the web server process, thereby avoiding the overhead associated with forking processes within the HTTP daemon.
• Simultaneous CGI requests will load the CGI script to be copied into memory once per request. With servlets, there is only one copy that persists across requests and is shared between threads.
• Only a single instance answers all requests concurrently. This reduces memory usage and eases the management of persistent data.
• A servlet can be run by a servlet container in a restrictive environment, called a sandbox. This is similar to an applet that runs in the sandbox of the web browser. This enables restricted use of potentially harmful servlets. CGI programs can of course also sandbox themselves, since they are simply OS processes.

　　Technologies like FastCGI and its derivatives (including SCGI, WSGI) do not exhibit the performance disadvantages of CGI incurred by the constant process spawning. They are, however, roughly as simple as CGI.