Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


Analyzing thread profiling

Posted on 2013-06-21
Medium Priority
Last Modified: 2013-07-18
hi guys

I have 11 threads(ThreadTaskExecutor) running on a 2CPU (12 cores)

Attached is the screenshot of my threads.
Any idea what the 4 states mean (at the bottom right of the image)

From the screenshot it looks like most of the threads are in
Monitor state.
How can i improve the performance (increase / decrease number of threads ?)

Any help will be greatly appreciated

Question by:royjayd
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 3
LVL 16

Expert Comment

ID: 39266040
is it screenshot from JProfiler?
It looks like only one thread is dedicated for your concurent thread pool.
If you have 12 cores it's the right decision to have 12 working threads, but it's difficult for me to understand why the picture is like this without the code.
read this article to understand how to utilize all of the CPU cores. It's short and very good:

btw state 'monitor' is BLOCKED state, in which the thread is waiting to obtain a lock on an object, but it's not able to, because some other thread already hold this lock.
LVL 36

Expert Comment

ID: 39266098
If you follow the diagram through you will see that 90% of the time, only 1 of your 11 threads are actually running at any point in time, and (as you said) the rest of the time they are in Monitor state. In case you don't know, Monitor state means that the thread is blocked waiting to get a hold of a lock (or monitor, hence the state's name).

So either your code uses an explicit Lock object or implicitly via "synchronized" methods it is manipulating locks, and in a way that will never be good for multithreaded execution, ie. no matter how many threads you allocate, more or less, it won't significantly change the performance. You need to look at the code that is being run to see why there is so much "lock contention".

Can you post the code?

Author Comment

ID: 39266198
Its the screenshot from VisualVM profiler

Regarding the code:
My code is a single java process which executes a batch task.
The task is to select data from one table and insert it into another table.
Here is the snapshot of code


<tasklet transaction-manager="transactionManager"
task-executor="threadTaskExecutor" throttle-limit="10">
<chunk reader="itemReader" 
commit-interval="5000"  />

<beans:bean id="threadTaskExecutor" class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<beans:bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
p:dataSource-ref="dataSource" />

Open in new window

itemReader - SELECT COL1 as value1,COL2 as value2 from TABLE1
itemWriter - INSERT INTO TABLE2(COL1,COL2) values (:value1,:value2)

TABLE1 has 1 million rows
so the above process writes/inserts 1 million rows from TABLE1 to TABLE2
and this task is distributed among 11 threads.
I have a ProcessMain class with a main() which invokes the
above tasklet in SPRING_CONFIG.xml

public class ProcessMain{
public static void main(String args[]) {

ThreadPoolTaskExecutor threadPoolTaskExecutor = null;
ApplicationContext applicationContext = new ClassPathXmlApplicationContext(SPRING_CONFIG);
try {
threadPoolTaskExecutor = (ThreadPoolTaskExecutor) applicationContext.getBean("threadTaskExecutor");
threadPoolTaskExecutor.setCorePoolSize(11); //configure 11 threads
} catch (Exception e) {
logger.error("exception ..woohoo", e);

//invoke <tasklet> xml

Open in new window

So as you can see there is no synchronization being used.
Any idea how i can improve the performance.
The whole process takes more than 30 minutes,

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

LVL 36

Accepted Solution

mccarl earned 1400 total points
ID: 39267702
So as you can see there is no synchronization being used.
Ahh, that's not necessarily true. YOU may not have implemented any synchronization, but that doesn't mean the code libraries that you are using haven't.

Refer to Spring Batch doco, section 7.1   http://static.springsource.org/spring-batch/reference/html/scalability.html

In particular the last couple of paragraphs of that section. It is all very helpful, but this following sentence is the most pertinent...
In particular most of the off-the-shelf readers and writers from Spring Batch are not designed for multi-threaded use
And one of the reasons for these issues.. think about you above SELECT statement. If that is executed by 11 threads in parallel, then each 1 of those threads are going to read every record from TABLE1.

To be able to do any parallel processing of this type of task, and have any hope of improving performance, then YOU need to devise a way of partitioning the work of reading (and subsequently writing) the 1 million records. Whether there is some column in that table that would allow you to easily divide up the work? And then I would recommend reading a lot more of that Chapter 7 of the Spring Batch doco that I linked, to work out the best way of implementing it.

We don't have enough details about what you are trying to do, and the data in the DB to really help you much more on how to improve performance.

Author Comment

ID: 39275422
little consufed now..if the readers and writers are not designed for multithreaded use
then why is there a option to use the ThreadpoolTaskExecutor
something like

i am doing something like

 <step id="copyDataStep" next="nextTask">
<tasklet transaction-manager="transactionManager"
task-executor="threadpooltaskexecutor" throttle-limit="10">

<beans:bean id="threadpooltaskexecutor"
<property corepoolsize = "10" >

why is there a 'task-executor' option, do  you know?

LVL 16

Assisted Solution

Valeri earned 600 total points
ID: 39277214
Wow, I didn't know that this is the case.
If all of this is related to DB operation, then you don't need thread pool at java at all.
In your case every thread is responsible to move all of the data from table1 to table2, it means that at the end the job is completed 11 times (by every thread).
I'm agree with the previous post, ThreadPoolTaskExecutor's should be used if you have a criteria to assign a smaler part of the task to each thread, so when all of the threads complete, it will mean that the whole task is completed.
for example if you have to calculate sum of 100 elements in fastest way, and you have 10 threads, the first should sum 1-10, the second 11-20...
But it's not applicable in your case.
Every DB has mechanism to do such as operations in parallel mode /in fastest way/.
In my opinion you have to ask this question in DB topic. If your DB is Oracle, go to ORACLE topic and ask: "How to move 1 million records from one table to another is fastest way"

Author Comment

ID: 39282850
>>In your case every thread is responsible to move all of the data from table1 to table2, it means that at the end the job is completed 11 times (by every thread).

that is not the case for me. so what you mean is since every thread is moving data from table1 to table2 there would be 11 million rows (one million by each thread)
but that is not the case, i see only one million in table2.
so in thoery what you said makes sense but practically that is not happening.

>>for example if you have to calculate sum of 100 elements in fastest way, and you have 10 threads, the first should sum 1-10, the second 11-20
how would you go about doing this ? I mean how would you assign
thread1 to sum 1-10
thread2 to sum 11-20
and so on..

Can you post some code ?

LVL 16

Expert Comment

ID: 39289206
Partitioning of the task is up to developer. Especially for partitioning of array you can check this article:


it's a generic class that partitions a List to subLists.

Author Comment

ID: 39318790
hi Valeri and mccarl

I looked into the code and i take back my statement.
""So as you can see there is no synchronization being used"

Actually I am reading the data synchronously...so revisiting my code i have
<tasklet transaction-manager="transactionManager"
task-executor="threadTaskExecutor" throttle-limit="10">
<chunk reader="itemReader"
commit-interval="5000"  />

<beans:bean id="itemReader" parent="synchItemReader">
<beans:property name="delegate" ref="stageReader" />

<beans:bean id="synchItemReader"       class="com.xmon.batch.SynchItemReader" abstract="true" />

package com.xmon.batch;

import org.springframework.batch.item.ExecutionContext;
import org.springframework.batch.item.ItemReader;
import org.springframework.batch.item.ItemStream;
import org.springframework.batch.item.ItemStreamException;
import org.springframework.batch.item.NonTransientResourceException;
import org.springframework.batch.item.ParseException;
import org.springframework.batch.item.UnexpectedInputException;

public class SynchItemReader<T> implements ItemReader<T>, ItemStream {

	private ItemReader<T> delegate;
	public synchronized T read() throws Exception, UnexpectedInputException,
			ParseException, NonTransientResourceException {
		return delegate.read();

	public ItemReader<T> getDelegate() {
		return delegate;

	public void setDelegate(ItemReader<T> delegate) {
		this.delegate = delegate;


Open in new window

As you can see the read() which reads the data from the table is synchronized
so now i unserstand why so many threads are in monitor state.

Any sugesions on how i can improve the performance.
LVL 36

Expert Comment

ID: 39319653
Any sugesions on how i can improve the performance.
As we said earlier, probably the only way to increase performance is... for you to find some property of your data that will allow you to partition this process among the threads, ie. say you have an id column in this table with values from 1 - 1000000 for the 1 million rows that it stores, then you would partition the work so that the first thread does "select * from TABLE where id >= 1 and id <= 100000" and the second thread does "select * from TABLE where id >= 100001 and id <= 200000", etc, etc.

The link that I posted above mentions that Spring-Batch comes with an example (parallelJob) that sounds pretty much like what you are trying to do, so that might be a starting point.

Featured Post

[Webinar] Lessons on Recovering from Petya

Skyport is working hard to help customers recover from recent attacks, like the Petya worm. This work has brought to light some important lessons. New malware attacks like this can take down your entire environment. Learn from others mistakes on how to prevent Petya like worms.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

After being asked a question last year, I went into one of my moods where I did some research and code just for the fun and learning of it all.  Subsequently, from this journey, I put together this article on "Range Searching Using Visual Basic.NET …
By the end of 1980s, object oriented programming using languages like C++, Simula69 and ObjectPascal gained momentum. It looked like programmers finally found the perfect language. C++ successfully combined the object oriented principles of Simula w…
This tutorial covers a step-by-step guide to install VisualVM launcher in eclipse.
This tutorial explains how to use the VisualVM tool for the Java platform application. This video goes into detail on the Threads, Sampler, and Profiler tabs.
Suggested Courses

618 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question