From the Head First Java book, I know that threads in java doesn't run parallelly, but JVM just switches between the threads which seem to us like running parallelly. And these threads run in a single JVM which itself a process that runs in one core of the Computer.
Here is the content from the book - " With more than one call stack, you get the appearance of having multiple things happen at the same time. In reality, only a true multiprocessor system can actually do more than one thing at a time, but with Java threads, it can appear that you’re doing several things simultaneously. In other words, execution can move back and forth between stacks so rapidly that you feel as though all stacks are executing at the same time. Remember, Java is just a process running on your underlying OS. So first, Java itself has to be ‘the currently executing process’ on the OS. "
My doubt is, does the tomcat threads and application server threads which are created per user request are also not run parallelly but JVM which runs on a single core (on which application server runs) just switches between the threads?
OR does threads really run parallelly on different cores?
I have been struggling with this question since many days. I have googled lot about this, but couldn't find the answer. So posting it here, hoping someone can help me.
Thank you.
Related
We have a computationally demanding java program (scientific research) that is designed single-threaded. However, when executed, it loads much more than 1 CPU core (we noticed it the hard way - cluster job scheduler killed our program because it loaded more cores than requested). We encountered this weird phenomenon both on linux (Debian, Ubuntu) and windows (7).
I understand that there are several background threads added by java/jvm (garbage collector) so even single-threaded program can load more than one core but I doubt that these background processes could load another full core or two.
I ask for any idea what may be causing this. Thanks for any hints. Feel free to ask for any details, though I can't post the code here (first, it's quite a lot of code, second, it is still under research and I cannot publish anything yet).
Let me first give you my condolences for having to run your program in an environment where someone has found it more intellectually fulfilling to kill jobs attempting to use more than one core, than to restrict jobs to using just one core. But let's move on with the question.
When I pause a random single-threaded java program and look at my debugger's thread listing there is about half a dozen threads in there. That's just how the JVM works. There is at least one thread for the garbage collection, another thread for running finalizers, and various other stuff, most of which I don't even know what purpose they serve. We lost the game of knowing precisely what is going on in our machines a couple of decades ago.
There may be options that you could use to tell the JVM to reduce its use of threads, for example to run garbage-collection in the same thread as your program, but I don't know them by heart, so you would need to look them up, and frankly, I doubt that it would make much difference. There will always be threads that you have no control over.
So, it seems like you are going to have to configure your own job to not use more than one core. I have done it at work, with some success, but today is Saturday, so I do not have access to the script files that I used, so I am going to try and help with whatever I remember.
The concepts you are looking for are "process thread affinity" and "NUMA".
Under Windows, the start command (built into cmd.exe) allows you to specify the number of logical CPUs (in other words, cores) to run your process on. start /affinity 1 myapp will run myapp limiting it on core 1.
Under Linux there are at least a couple of different commands that allow you to launch a process on a limited subset of cores. One that I know of is taskset and another is numactl.
There are set of parameters for JVM you could play. For Java 7 and earlier:
-XX:ParallelGCThreads=n Sets the number of threads used during parallel phases of the garbage collectors.
-XX:ConcGCThreads=n Number of threads concurrent garbage collectors will use
For Java 8 there are another options which depends on OS. You could see them for Windows here. Some you could find helpful:
-XX:CICompilerCount=threads Sets the number of compiler threads to use for compilation
-XX:ConcGCThreads=threads Sets the number of threads used for concurrent GC. The default value depends on the number of CPUs available to the JVM (!possible cause of your problem!)
-XX:ParallelGCThreads=threads Sets the number of threads used for parallel garbage collection in the young and old generations. The default value depends on the number of CPUs available to the JVM
-XX:+UseParNewGC Enables the use of parallel threads for collection in the young generation. By default, this option is disabled (but it could be enabled due to another options)
If you provide us additional info then answers would be more helpful and informative
I've just started programming in Java, and I'm interested in how computers distribute their CPU load. I have made a very basic program that creates a window and makes a box and line move. While testing this, I looked at Task Manager; Task manager said I was using ~1% of my CPUs. however, when I ran my program, the CPU usage went up to ~36% (I only started the program, nothing else). Can anyone tell me what is going on here, please?
You think that your program has only one thread, but in reality every Java program has lots of threads. GUI apps have the Event Dispatch Thread, garbage collection has its own thread etc. You can use a profiler (like the VisualVM that is in the JDK) to see all the threads in your app.
Or you can see them programmatically, see Get a List of all Threads currently running in Java
Unix daemon runs a script a loop, the script calls a java program: java {java_args} myClas.jar
The java program is heavy program with multiple threads.
The problem is very strange: First execution works as expected.
But the second execution is stuck some where and I can't find a reason (very hard to debug this).
Is there a possibility that when first execution is finished there are still not-cleaned resources or threads left from this execution?
If yes, is it possible to clean and kill everything right after process completes?
If by resources, you mean threads, then no. When the VM shuts down, everything on the heap, all threads, objects and monitors are disposed of. However if you're depending on the existence/absence of a file for locking or something similar, a deadlock is possible. Also, is it possible that the first process is still running when you launch the second one?
If your java process is stuck on the second run, you can attach jvisualvm to it and should be able to figure out where it's stuck.
I want to exit a java process and free all the resources before it finishes its normal running, if a certain condition is meet. I dont however want to quit JVM, as I have other java programs running at the same time. Does return; do the above, or is there a better way to do it?
Thanks.
There is one JVM process per running Java application. If you exit that application, the process's JVM gets shut down. However, this does not affect other Java processes.
You need to understand the JVM mechanism and clarify the terminology.
Let's use the following as datum for the terminology.
Threads are divisions of concurrently processed flows within a process.
A process is an OS level thread. The OS manages the processes. A process is terminated by sending a termination signal to the OS management. The signal may be sent by the process itself or by another process that has the applicable privilege.
Within a process, you can create process level threads. Process level threads are normally facilitated by the process management of the OS, but they are initiated by the process and terminated by the process. Therefore, process level threads are not the same as processes.
An application is a collection of systems, programs and/or threads that cooperate in various forms. A program or process within an application may terminate without terminating the whole application.
Within the context of JVM terminology, program may be one of the following.
A program is run per JVM process. Each program consumes one JVM process and is invoked by supplying the classpath of java bytecode and specifying the main entry point found in the classpath. When you terminate a java program, the whole jvm process that ran that program also terminates.
A program is run per process level thread. For example, an application run within a tomcat or JEE server is run as a thread within the JEE process. The JEE process is itself a program consuming one JVM process. When you terminate an application program, the JEE process does not terminate.
You may initiate process level threads within a java program. You may write code that terminates a thread but that would not terminate the process (unless it is the last and only running thread in the process). The JVM garbage collection would take care of freeing of resources and you do not need to free resources yourself after a process level thread is terminated.
The above response is simplified for comprehension. Please read up on OS design and threading to facilitate a better understanding of processes and the JVM mechanism.
If the other threads running concurrently are not daemon threads, leaving main will not terminate the VM. The other threads will continue running.
I completely missed the point though.
If you start each program in a separate JVM, calling System.exit() in one of them will not influence the others, they're entirely different processes.
If you're starting them through a single script or something, depending on how it is written, something else could be killing the other processes. Without precise information about how you start these apps, there's really no telling what is going on.
#aix's answer is probably apropos to your question. Each time you run the java command (or the equivalent) you get a different JVM instance. Calling System.exit() in one JVM instance won't cause other JVM instances to exit. (Try it and see!)
It is possible to create a framework in which you do run multiple programs within the same JVM. Indeed this is effectively what you do when you run a "bean shell". The same sort of thing happens when your "programs" are services (or webapps, or whatever you call them) running in some application server framework.
The bad news is that if you do this kind of thing, there is no entirely reliable way make an individual "program" go away. In particular, if the program is not designed to be cooperative (e.g. if it doesn't check for interrupts), you will have to resort to the DEPRECATED Thread.stop() method and friends. And those methods can have nasty consequences for the JVM and the other programs running in it.
In theory, the solution to that problem is to use Isolates. Unfortunately, I don't think that any mainstream JVMs support Isolates.
Some common usecases leading these kind of requirements can be solved through tools like Nailgun, or Drip.
Nailgun allows you to run what appears to be multiple independent executions of a commandline program, but they all happen in the same JVM. Therefore repeated JVM start-up time does not have to be endured. If these execution interact with global state, then the JVM will get polluted in time and things start to break up.
Drip will use a new JVM for each execution, but it always keeps a precreated JVM with the correct classpath and options ready. This is less performant, but it can guarantee correctness through isolation.
We've been talking about threads in my operating system class a lot lately and one question has come to my mind.
Since Go, (and Java) uses User-space thread instead of kernel threads, doesn't that mean that you can't effectively take advantages of multiple cores since the OS only allocates CPU time to the process and not the threads themselves?
This seems to confirm the fact that you can't
Wikipedia also seems to think so
What makes you think Go uses User-space threads?
It doesn't. It uses OS-threads and can take advantage of multiple cores.
You might be puzzled by the fact that by default Go only uses 1 thread to run your program. If you start two goroutines they run in one thread. But if one goroutine blocks for I/O Go creates a second thread and continues to run the other goroutine on the new thread.
If you really want to unlock the full multi-core power just use the GOMAXPROCS() function.
runtime.GOMAXPROCS(4); //somewhere in main
Now your program would use 4 OS-threads (instead of 1) and would be able to fully use a e.g. 4 core system.
Most recent versions of Java to use OS threads, although there is not necessarily a one-to-one mapping with Java threads. Java clearly does work quite nicely across many hardware threads.
I presume that by "user-space threads" you mean (for example) Go's goroutines.
It is true that using goroutines for concurrency is less efficient than designing (by hand and by scientific calculations) a special-purpose algorithm for assigning work units to OS threads.
However: Every Go program is situated in an environment and is designed to solve a particular problem. A new goroutine can be started for each request that the environment is making to the Go program. If the environment is making concurrent requests to the Go program, a Go program using goroutines might be able to run faster than a serial program even if the Go program is using just 1 OS thread. The reason why goroutines might be able to process requests with greater speed (even when using just 1 OS thread) is that the Go program will automatically switch from goroutine A to goroutine B when the part of environment which is associated with A is momentarily unable to respond.
But yes, it is true that using goroutines and automatically assigning them to multiple OS threads is less efficient than designing (by hand and by scientific calculations) a special-purpose algorithm for assigning work units to OS threads.