How does Java ensure internally that only one instance of an ENUM would exist per JVM? Is it created when application boots up and from that point on when multiple threads access it, it will just return the object created at startup?
Or does it implement some kind of double synchronization similar to the singleton pattern so that even if multiple threads access it, only one istance will be created?
as you can read in this answer enum instances are static class fields and so are initialized as part of class loading when you 1st access the class.
classloading is synchronized internally so that ensures enum instances are singletons (singletons within the same classloader, that is. if you have the same enum loaded by multiple loaders you will get multiple instances)
Enum instances are created at class loading time. If the same enum gets loaded by more than one classloader (when classloading games are being played by, for example, a web app container), you will have multiple incompatible instances in memory.
Related
Classes are a software bundle of variables and functions, also known as a blueprint that defines the variables and methods common to objects of a certain kind. So why are objects also known as instances of a class?
Like you said, class is a blueprint; objects are made using those blueprints.
Its like you have a blueprint of a car - you have one blueprint, but many cars based on that blueprint.
According to dictionary.com: An instance is - "an example or single occurrence of something"
An object is a single occurrence or realization of a class.
Class is a syntactic notion, governed by compile time rules, such as naming, scope, etc. That your program defines a class A means that 1) you have a type, and 2) that the right class loader will be able to find A's bytecode on the classpath. But it doesn't mean that your running program is able to operate on this class. An operable object with its own state must be first instantiated with new, which, at run time, will cause the classloader to allocate memory required to hold that state. You can have any number of objects of a single class A, all of type A but with their own state memory.
If i have multiple instances of singleton class on different class loaders
and if i have modifications to a reference variable in any of these instances.
E.g if i add/remove an element to Hashmap
Does the change/modification impact the instances on other class loaders as well?
Singleton is per classloader. so changes wont impact other instances loaded using other classloaders.
there are couple of good references:
on Singleton and different classloaders
on Static members and different classloaders
Your "singleton" is one instance per JVM.
Here is a good article discussing classloaders, the relationship between different classloaders to each other, and to the JVM:
http://javapapers.com/core-java/java-class-loader/
When I access a singleton Java object from withing a servlet, that object is only "single" or "one instance" for the give servlet thread or single throughout the JVM on the Server OS (like Linux)?
I mean when client connects to the servlet/service, are singleton object are unique to each thread created for each client or its unique throughout the whole JVM installed in the machine?
I think the object is unique for each user, not to the whole JVM. The only persistent information is the one you put in the user session.
I'm not sure, but I think you can acomplish to have one instance of a Class in the whole Application Server using the ClassLoader class, however I don know how it's done.
UPDATE:
Taken from the Java Article "When is a Singleton not a Singleton?"
Multiple Singletons Simultaneously Loaded by Different Class Loaders
When two class loaders load a class, you actually have two copies of the class, and each one can have its own Singleton instance. That is particularly relevant in servlets running in certain servlet engines (iPlanet for example), where each servlet by default uses its own class loader. Two different servlets accessing a joint Singleton will, in fact, get two different objects.
Multiple class loaders occur more commonly than you might think. When browsers load classes from the network for use by applets, they use a separate class loader for each server address. Similarly, Jini and RMI systems may use a separate class loader for the different code bases from which they download class files. If your own system uses custom class loaders, all the same issues may arise.
If loaded by different class loaders, two classes with the same name, even the same package name, are treated as distinct -- even if, in fact, they are byte-for-byte the same class. The different class loaders represent different namespaces that distinguish classes (even though the classes' names are the same), so that the two MySingleton classes are in fact distinct. (See "Class Loaders as a Namespace Mechanism" in Resources.) Since two Singleton objects belong to two classes of the same name, it will appear at first glance that there are two Singleton objects of the same class.
I'd say it depends on how the singleton is implemented, but all requests for a given app execute in the same VM, so it should be one instance for all requests.
EDIT: This is assuming a straight-forward Singleton implementation similar to:
public class MySingleton {
private static MySingleton _instance;
// for sake of simplicity, I've left out handling of
// synchronization/multi-threading issues...
public static MySingleton getInstance() {
if (_instance == null) _instance = new MySingleton();
return _instance;
}
}
Yes it is Singleton. But the scope of the singleton depends on where the class is located.
If it is located inside application, it is singleton for that application. If the same class is present inside another application then another object is created for that application and it is singleton for that application.
If it is located outside application and within server, it is singleton for the VM.
According to this
https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html
every Web application has it's own class loader, so the singleton will be unique for one application and it can't be visible to another
When you create a Singleton instance, all request instances will share the same instance for the current class loader it uses.
Since all the Servlets run on a webserver which runs on a single JVM, there will be only a single Singelton Object for all your servlets.
It's impossible to use static variables on a session bean code. Is this restriction arbitrary or fundamented? And why?
Best regards
As stated in the FAQ on EJB restrictions, one of the restrictions for using EJBs is:
enterprise beans should not read or write nonfinal static fields
Further expanded in the discussion on static fields:
Nonfinal static class fields are disallowed in EJBs because such fields make an enterprise bean difficult or impossible to distribute. Static class fields are shared among all instances of a particular class, but only within a single Java Virtual Machine (JVM). Updating a static class field implies an intent to share the field's value among all instances of the class. But if a class is running in several JVMs simultaneously, only those instances running in the same JVM as the updating instance will have access to the new value. In other words, a nonfinal static class field will behave differently if running in a single JVM, than it will running in multiple JVMs. The EJB container reserves the option of distributing enterprise beans across multiple JVMs (running on the same server, or on any of a cluster of servers). Nonfinal static class fields are disallowed because enterprise bean instances will behave differently depending on whether or not they are distributed.
It is acceptable practice to use static class fields if those fields are marked as final. Since final fields cannot be updated, instances of the enterprise bean can be distributed by the container without concern for those fields' values becoming unsynchronized.
It is fundamental. As per this sun documenation,
Nonfinal static class fields are disallowed in EJBs because such fields make an enterprise bean difficult or impossible to distribute. Static class fields are shared among all instances of a particular class, but only within a single Java Virtual Machine (JVM). *
static means unique for a class OR for all it's objects.
Now, javabeans are supposed to have user-specific data, static fields don't make any sense for these.
One user edits a variable, ant it'll be updated for all other users too. (at free of cost :-)).
However if you want static behaviour for these (i.e. using same data for all users), you have application for that purpose.
hii every one
I m using Applets
i ve three classes ie three applets
and I need some members(variables) of one class into another class
when i m trying to access variables from one class to another class by creating of object of
called class in to calling class then it doesnt give wright output
it access those variables but gives null or zero values
I think that this isn't possible.
Won't each applet be loaded by a different classloader? Won't this mean that the class namespaces will be kept separate by the JVM?
If that is the case, you will either have 3 versions of each class in existence (with no sharing of state ...) or the classloader will fail because it cannot find the other 2 classes when loading the first of the applets.