Does invoking java via two different command line involves two different JVMs or two separate instances of same JVM.
JVM is Java Virtual Machine, a memory space where classes (code) are loaded and objects (data) are shared. JVM is equivalent to an Operating System process.
When you type java... in you command line you are executing an independent process that loads Java classes in memory, the base classes from Java and yours (from the .class files or .jar you indicate).
Another java... command will load a different process with its own memory and will load classes by itself.
Instance word confusion: when you say 'two instances of the same JVM'. It's usual to say instance of a JVM to a separate process, it is, to a loaded independent JVM. If you are saying: two process are running JVM 1.5, OK, it's the same JVM in the sense it's the same version but they are different processes, different 'instances', independent in all sense.
Webapp confusion: A webapp (by example) is simply a bunch of classes and objects instantiated, attending some URL in a web server. You can start Tomcat with 10 different apps -it is, 10 different bunches of classes and objects each of them attending different request, but in fact they share the same memory space (OS process). A webapp cannot touch other webapp's objects because nobody gives it a reference to the other objects (and classes are in some way hidden but that's another story called: class-loading).
What is the difference in your question? I would say: two different JVM instances. :)
Each run of the the java command does invoke a new JVM instance. The running java application could run new Java Threads (like a Tomcat does with web applications).
Two separate JVMs. You can run lots of stuff inside the same JVM (say 10 webapps served up by the same Tomcat instance), but there is only 1 java command to start tomcat.
If you started Sun's java.exe from their JDK/JRE version 1.6 from the same source path twice, you would get two separate and distinct JVM instances. There would be no sharing between them unless you configured it via your applications. If you wanted two different JVM's running you would have to start a java.exe of one type (say 1.5) from one location and a java.exe (version 1.6) from another.
If you are using one JDK version to run your project for both instances, invoking java via two different command lines will involve two different instances of the same JVM
If you are using a different JDK version for each app, this will involve two different JVMs.
Related
By Simply Running same code in two Different eclipse can we say that code is running in two different jvm on same system.
No. The JVM is a virtual machine the Java uses. Eclipse just runs programs on that virtual machine. It doesn't create it.
If you install two different eclipse versions and set one eclipse to run on some specific JVM as explained here
and the other to run on another JVM, then you can have them running on different JVMs on one machine. But there's no point in doing that
If you're wondering whether you can use two different JVM versions by launching them different eclipse setups, that could be possible.
If you're wondering whether they'll run in the same JVM instance, the answer is no. For example, if you intend to use a synchronized function to limit access to a shared resource like a file, it's not going to work because that will only work within the same JVM instance. If you want to isolate your applications so that one can use all available memory without impacting the other, yes, they'll be isolated by running them from different eclipse instances.
You actually don't even need to start Eclipse twice. You can run your app twice from the same Eclipse.
Is the same JVM used by all Java applications running or, does 'one JVM per Java application' apply? (say the applications are IntelliJ IDEA, a server and NetBeans for example)
Further, is there any connection between JVMs assigned and processes used by each Java application?
Generally speaking, each application will get its own JVM instance and its own OS-level process and each JVM instance is independent of each other.
There are some implementation details such as Class Data Sharing, where multiple JVM instances might share some data/memory but those have no user-visible effect to the applications (except for improved startup time, hopefully).
A common scenario however is a single application server (or "web server") such as Glassfish or Tomcat running multiple web applications. In this case, multiple web applications can share a JVM.
There's one JVM per Java application. There shouldn't be any connection between them unless you establish one, e.g. with networking. If you're working inside of an IDE, the code you write generally runs in a separate JVM. The IDE will typically connect the separate JVM for debugging. If you're dealing with multiple web applications they could share the same JVM if they're deployed to the same web container.
In theory you can run multiple applications in a JVM. In practice, they can interfere with each other in various ways. For example:
The JVM has one set of System.in/out/err, one default encoding, one default locale, one set of system properties, and so on.
If one application changes these, it affects all applications.
Any application that calls System.exit() kills all applications.
If one application thread goes wild, and consumes too much CPU or memory it will affect the other applications too.
Short answer: often, yes, you'll get one application per JVM.
Long answer: the JVM can be used that way, and that may be the best option, but it doesn't have to be.
It all depends on what you consider to be an 'application'. An IDE is a good example of an application which is presented to its end users (i.e. us) as a single entity but which is actually comprised of multiple underlying applications (compilers, test runners, static analysis tools, packagers, package managers, project / dependency management tools, etc). In that case there are a variety of tricks which the IDE uses to ensure that the user experiences an integrated experience while also being shielded (to some extent) from the individual vagaries of the underlying tools. One such trick is to do some things in a separate JVM, communicating either via text files or via the application-level debugging facilities.
Application servers (Wildfly, Glassfish, Websphere, Weblogic, etc) are applications whose raison d'etre is to act as containers for other applications to run in. In that case, from one perspective, there's a single JVM per application (i.e. one JVM is used to run the entire application server) but there are actually multiple applications contained within that JVM in their own right, each logically separated from each other in their own classloader (reducing the possibility of accidental in-process crosstalk).
So, it all really depends on what you consider an application to be. If you're purely talking about "the thing which runs when 'main()' is called", then you're looking at one application per JVM - when the OS starts the JVM, the JVM runs a single class's public static void main() method.
But once your applications start getting more complicated your boundaries become more blurred. An IDE such as Intellij or Eclipse will reuse much of the same stuff as 'javac', either in the same JVM or a different one, as well as doing different work (such as repainting the screen). And users of a web application on a (shared JVM) application server may actually be using much the same 'core' application as could be used locally via the command line.
Number of JVMs running is the number of executables invoked.
Each such application invokes its own java executable (java.exe/ javaw.exe etx for windows) which means each is running in a separate JVM.
Any application which has shared libraries will share the same copy of those libraries. Java has a fair amount of shared libraries. However, you won't notice the difference except for some memory saved.
Little late here however this info may be useful for somebody. In a Linux system, if you want to know how many JVMs are running you can try this command
$ ps -ef | grep "[j]ava" | wc -l
ps to list process, grep to search process containing "java" and wc to count lines returned
Actually this is one question that can have very confusing answers. To keep it real short:
Yes per java process, per JVM.
Runtime and ProcessBuilder follow this rule.
Loading jars using reflection and then executing the main won't spawn new JVM.
What do two different Java programs, running in one same Java Virtual Machine, share together?
Something comes to my mind, regarding singleton classes: They can only be instantiated once per JVM. This means that if two different Java programs use one same class, they are both accessing the same instance of that Singleton class?
What other things are shared?
If you run the java command multiple times, you get multiple instances of the JVM. In theory these are entirely separate with nothing shared, but some implementations of the JVM (now or in the past) might attempt to share some portions of the data.
I haven't looked at it recently, but about 10 years back there was a version of the Sun JVM that would attempt to "share" .class file images between JVM instances. (This was supposedly useful on servers where there might be dozens of JVMs running at once and they might come and go fairly rapidly.)
I'm not recalling any other data shared, but there may have been more, or other data may have been added since. (Though there really isn't much else that can be shared between JVMs.)
But again, in theory this should all be "transparent" and not affect the operation of an individual JVM instance.
There was also a provision for "warm started" JVMs that were partially loaded prior to the final command. This did require some configuration on the part of the system admin, but was otherwise transparent.
Two or more programs running in the same JVM shares everything. Regarding singleton, when written properly there will be one single instance of the class, which can be accessed by all the other objects.
If i run a same multithreaded program from multiple command prompt, what would happen? Each command prompt will run in diffrent jvm. how the shared resources will access by threads in different jvm?
If i run a same multithreaded program from multiple command prompt,
what would happen?
there is seperate JVM for each program or application. (whether application is same or different)
how the shared resources will access by threads in different jvm?
As Same multithreaded application is executed by different JVM there is nothing(resources) to share by different JVM's.
As there are different java application are running same time(multiprocessing) shared resources of machine(memory , processor etc.) are handled by OS.
Note:IF you are asking about shared resources in single multithreaded application please refer oracle docs
Assuming the JVM isn't doing voodoo magic (knowing Oracle I can't be sure) each instance of Java would be running it's own thing and allocating it's own resources. As for how the host handles threading and resource distribution is a whole nother subject with tons of discussion and no good answer on how to do it (other than "Correctly")
To share resources among different JVM you need an external player, a Redis DB or similar, however if your program is multithread, why do you need to run different process ? Why don't you run it just one time ?
Each command prompt will run in diffrent jvm - Yes.
Among different jvms Resource sharing will be decided by operating system.
If two instances of JVM run the same multi threaded application, you cannot do resource sharing. Remember, resource sharing and concurrency control is between multiple threads running a single JVM process. Two such JVM processes, running the same application code, cannot do any concurrency control and resource sharing. For example, if the first JVM process opens a file, the second JVM process will not be able to access that file.
I hope this answers your question. If there is something specific which you are trying, then describe that, so that, we can offer you suggestions.
I have implemented one application using JDK 1.6 64-bit, JSF, Tomcat server 64-bit etc at user system.I am integrating some devices(i.e. finereader, scanner, etc) into this application. Some of devices libraries are supported only on JRE 32-bit Only.
So, device integrated screens to be run on JRE 32-bit and non device screens should be run on a JRE 64-bit. Can I configure multiple JRE's in the same application? If possible, how?
A Java application runs in a JVM. The JVM is part of one single JRE. You could split your application into two parts, which each run in their own JVM. These applications then would have to communicate with each other to coordinate the user experience. This does not look like a good solution to me.
It all depends on how you define "application."
First, in regard to your question, each JVM instance runs a single kind of Java--32 or 64 bit--Java version and such.
Sometimes, an application consists of a single JVM running a single java executable, usually a jar and some stuff on the classpath with a single 'main'
Sometimes, an application consists of multiple JVMs running on one or more boxes. In this case, each JVM is running a single java executable. But there has to be some sort of communication between these executable parts to make it function as an application.
Alternatively, the same executable might run on multiple JVMs and we still call it one application. In this case, there would be some sort of outside stuff that decides how to allocate the work of the application amoung the multiple JVMs. For example, you could run 18 instances of Tomcat on 9 boxes with a hardware load balancer dividing up the network requests and assigning each one to one of the Tomcat instances. In this case, though, part of the application is probably running on 1000's of user's computers inside a browser.
Sometimes, we say multiple applications are running under another application. In this case, we might call the master application a container. One example is Tomcat. In this case, Tomcat manages the load of requests for each of the separate applications because the HTTP requests come in off the network with information in the header indicating which one handles that request.
You already say that you have some code running under Tomcat. Tomcat is a single executable (It runs in one JVM and has one variety of Java) and it manages running your one Java executable supplied as a .war file, usually. There could be other Java applications running in other JVMs that communicate through that Tomcat and with your executable. Or there might not be other JVMs that your executable communicates with running somewhere else.
So, you can see, the real answer is "it depends." If you have multiple JVM communicating in some way, you could have different Java varieties. If it's all running under a single Tomcat instance, then you have a single variety of Java.