I am starting with the assumption that a single core machine can run only a single thread. Now I wrote a java/spring based junit test that spawns 20 threads and they calculate factorial of a large number using BigDecimal.
I monitored that junit with Visual VM and I can see all 20 threads working and show up as running (Green) in visual VM. As I understand, the jvm makes them look like as if they are all running but at the very granular level, there each thread will be taking turn for CPU cycles. Is there a way or tool to prove visually or by numbers that all threads do interfere with each other and CPU switches from one thread to another? Or in other words, I want to see for a given number of threads that do a given function, what is the saturation point or diminishing return due to extreme context switching by CPU.
The actual problem that I need to solve is to tune threads in a large java application. If I can't see thread contention in a sample run then I won't be able to see thread contention/abuse in large application too.
Is there a way or tool to prove visually or by numbers that all threads do interfere with each other and CPU switches from one thread to another?
The short answer is "no". You might be able to determine which threads are actually working by looking at the cloned processes listing in extended ps output if on a Linux system but even then I'd doubt you'd be able to get the resolution that you need to make that information useful. Then you have the Hiezenberg problem that if you were sampling fast enough, you'd dramatically affect the performance of the box you were trying to monitor. You could look at the cpu time each thread is used and make some sort of determination although that CPU time may include context switch overhead.
If you are trying to figure out what the optimal number of threads for your application is, then I'd suggest doing a number of test runs to determine the optimal throughput of different thread-pool sizes. Of course if you switch architectures, you are going to have to re-run the test since it is very dependent on CPUs, cores, memory, etc..