This question already has answers here:
How many threads can a Java VM support?
(13 answers)
Closed 9 years ago.
we are developing a game using Java as a server side programming. and i have no knowledge on Java to be honest.
We are using 7-10 threads, for a table and there are 80-100 tables max, this is coming upto 1000 threads running backend.
How bad it is, will this screw up the application on a longer run ??
Thanks for your inputs
Thanks,
Satish.
Check this answer. It'll explain most of the things:
How many threads can a Java VM support?
Also consider redesigning your application.
My first thought is: don't do this. If you have an application that requires multiple threads then that's fine. However consider that your computer's underlying architecture (processor) can only run so many threads at a time. The Operating System (OS) simulates multi-tasking by constantly switching which thread is executing at any given time. For example, if you have a simple single core processor, only one thread can be run on it at a time, so the OS will have to swap the currently executing thread if there is more than one. Of course, this over simplifies things and ignores all the other applications running on your computer, but that's the general idea of things.
If you have lots of tasks that can be threaded, consider using a thread pool (or using a library to do it for you) where you have a set number of threads that will run tasks from a queue.
Don't do this. Threads need to be owned by a process, not an entity like a Table. Used a ThreadPool, often ScheduledThreadPoolExecutor tends to work for most cases, and tables should request access to this resource.
Related
I've been asked to convert an application (relatively small one) from Python to Java since all the machines in adjacent branches have Java but not Python (and no .exe generator).
The gist of the application is a map that displays lines or polygons based on a variety of user chosen calculations. There is very minimal I/O in the program (at this state) and that which exists sits on a separate thread from the GUI. Currently the calculations are handled via multiprocessing, as there may be as many as 15 "packages" containing 10,000 calculations. Our systems have 32 cores (16 + 16 HTT) and the program was successfully implemented using a method similar to the first answer on this SO post. Essentially, each "package" is put into its own process and a Queue shares the results and the GUI updates.
My Java experience is all CLI based; I've messed around with some sample GUI's (making a button and what have you) but nothing nearly this complex. However, from the SO searching and Google results, it doesnt appear that multiprocessing would be the way to go. In fact, most answers say that multithreading is the way to go. Now, I believe this is where my Python-isms cause me a problem, as in Python the GIL prevents concurrent threads from executing (unless one starts using async implementations) and thus I switch to multiprocessing. I should note that the calculations require little overhead even when using 15 individual cores via the pool.map() method in Python; this implementation was chosen solely for concurrent CPU bound work.
Is my understanding of Python threading (and the terror that is the GIL) causing me unnecessary confusion in Java-land? Do Java threads run concurrently and there is no reason to say pull out 15 ProcessBuilders and run the JVM 15 times on a machine? I'm hoping not, thats a lot of resources!
My application is supposed to have a "realtime with pause" functionality. The user can pause execution, do some things that modify what's going to happen, then unpause and let stuff happen. Stuff happens at regular intervals as specified by the user, can be slow, can be fast.
My goal at using threading here is to improve performance on multicore systems. The amount of data that the application is supposed to crunch at the time intervals is supposed to be arbitrarily large (I expect lots and lots of loops over collections, modifying object properties and generating random numbers, but precious little disk access). I don't want the application to be constrained by the capacity of a single core, if it can use more to run faster.
Will this actually work this way?
I've run some tests (made a program crunch numbers a lot, and looked at CPU usage during its activity), but it's not really conclusive - usage is certainly in the proximity of 100% on my dual core machine, but hardly ever 100%. Does a single-threaded (main only) Java application use all available cores for computation?
Does a single-threaded (main only) Java application use all available cores for computation?
No, it will normally use a single core.
Making a program do computations in parallel with multiple threads may make it faster, but it's not a magical solution for any kind of problem. Whether this is a suitable solution for your program depends on what your program is doing exactly, and if the algorithm can be parallelized. If, for example, you are doing lots of computations where the next computation depends on the result of the previous computation, then making it multi-threaded will not help a lot, because you can't do the computations at the same time - the next one first has to wait for the answer of the previous one. So, you first have to think about what computations in your program could be run in parallel.
Java has a lot of support for multi-threading. You can program with threads directly, or use an executor service, or use the fork/join framework. Whatever is appropriate depends on what exactly you want to do.
Does a single-threaded (main only) Java application use all available cores for computation?
Not usually, but you could make use of some higher level apis in java that is actually using threads for you and youre not even usinfpg threads directly, more obviousiously fork/join and executors, less obvious the new Streams API on collections (ie parallelStream).
In general, though, to make use of all cores, you need to do some kind of concurrency. Further...its really hard to just observe you OS monitor to see what is going on (especially with only 2 cores)...your OS has other things going on (trying to manage itself, running your IDE, running crontab, running a browers to post to stackoverflow ;).
Finally, just implementing (concurrency) itself may not help, you have to do it "right" for your code/algorithm.
a java thread will run in a single cpu. to use multiple CPUs, you should have multiple threads.
Imagine that u have to do various tasks using your hand. You will do it slowly using one hand and more effciently using both your hands. Similarly, in java or in any other language multi threading provides the system with many hands. The good news is that you can have many threads to do different tasks. Running operations in a single thread will make the program sluggish and sometimes unresponsive. A good practice is to do long running tasks in a separate thread. For example loading large chunks of data from a database should be processed in a separate thread. Downloading data from the internet should also be processed in a separate thread. What happens if you do long running operations in the main thread? The program HANGS and will become unresponsive till the task gets completed and the user will think that there is someting wrong. I hope you get it
This question already has answers here:
Java thread affinity
(5 answers)
Closed 8 years ago.
I have an application that I need to run multithreaded but I want it to use only one core of the computer, as if my computer has single core (I know the behavior of multithreaded application on a computer with single core), although it is not.
This application is going to be deployed on a customer computer (Windows XP & 7) and I don't want my application to use more than one core. Can this be done? Does it depend on the programming language? Or all the thread management is left to the OS?
Thanks in advance.
You can set affinity of the whole program to bind to just one cpu.
In unix you can use taskset but for windows I only know how to do it from task manager which might not suit you.
I have a library, Java Thread Affinity which will allow you to set the affinity programatically.
AffinitySupport.setAffinity(1); // only run on cpu 0.
This will also limit any thread started from that point to the same affinity.
You could add a class with a main() which sets the affinity and calls your normal main() allowing you to add this without altering any of your existing code.
If you don't want to change your program source you can use the OS commands
On Linux you can use the tool cpulimit. More details here and here
On Windows you can use /AFFINITY parameter to the start command. More details here
I have certain requirement where I need to process large data with some mysql operation, there are multiple run of the similar kind. A single run takes around 2 hrs.
If I run each run in separate java thread there was no major time saving. As per my understanding java threads are not multi process ie its only a way to obtain parallelism not to improve CPU utilization.
If there is any way I can make use of multiple processor on the same machine through java, I guess that could save some time for all run operations.
Please let me know if the problem is clear here and have any idea on the solution.
Thanks,
Ashish
I think that your problem is in your application or in mysql.
Java does support multi-threading and your application should benefit automatically from multiple cores.
Probably there is a common resource that needs to be synchronized.
From what you say, "process large data", i bet the common resource is the database file and memory.
If a single run takes a minute or more (in your case: 120 minutes), than you're better off with multiple processes anyway, as the overhead of the JVM startup is neglectible.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java thread affinity
I have a server and it has a 16 cores cpu.
In Java, I need to create some threads (the number of threads is less than 16). Each thread needs to run some operations, e.g., process an event queue.
How can I create these threads so that it guarantees that each thread is assigned to one core forever? I mean I don't want the OS exchanging cores for one thread. I just wish one thread is dedicatedly running on a fixed core.
Can I do that?
The reason I want this is
I handle some background tasks (computation intensive) and some user-facing tasks in the same server. I don't want the user side get any negative impact. For example, if my computation tasks are assigned to 16 cores, surely the threads which are running for user side will be negatively affected, right?
You cant. JVM virtualizes all hardware so you can not do anything like that.
There could be some 'tricks' that would work on some specific architecture and some specific JVM, but it would all be hackish and unreliable.
Don't waste your valuable development time on this. Fix some other problems. If the time taken by OS core menagement is an issue for your app, it's teetering on the edge of failure anyway.
no you cannot do that since the OS Scheduler is meant to assign threads to cores. The JVM in which your java app runs does not have access to it.
You shouldn't.
If you really want to, you can use native calls : Java thread affinity
But really, be sure to have a good reason to do this. Why do you think that's a good idea ?