DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Coding
  3. Java
  4. A Scalable Java Thread Pool Executor

A Scalable Java Thread Pool Executor

The Java Thread Pool Executor is biased towards queuing rather than spawning new threads. On the bright side, we've got couple of workarounds.

Mohammad Nadeem user avatar by
Mohammad Nadeem
·
Jan. 18, 17 · Tutorial
Like (37)
Save
Tweet
Share
70.48K Views

Join the DZone community and get the full member experience.

Join For Free

Ideally, from any thread pool executor, the expectation would be the following:

  • An initial set of threads (core threads pool size) created up front, to handle the load.
  • If the load increases, then more threads should be created to handle the load up to max threads (Max pool size).
  • If the number of threads increases beyond Max Pool Size, then queue up the tasks.
  • If Bounded Queue is used, and the queue is full, then bring in some rejection policy.

The following diagram depicts the process; only initial threads are created to handle tasks (when load is very low).

tpe-core-threads

As more tasks come in, more threads are created to handle the load (task queue is still empty), assuming the total number threads created is less than max pool size.

tpe-extended-threads

The Task Queue starts to fill if the total number of tasks is more than total number of threads (initial + extended):

tpe-queue-filling-up

Unfortunately, Java Thread Pool Executor (TPE) is biased toward queuing rather than spawning new threads, i.e., after the initial core threads get occupied, tasks gets added to queue, and after the queue reaches its limit (which would happen only for bounded queues), extra threads would be spawned. If the queue is unbounded, then extended threads won’t get spawned at all, as depicted in the following image.

tpe-java-implementation

  1. Initial core threads were created to handle the load.

  2. Once there are more tasks than the number of core threads, the queue starts filling up to store the tasks.

  3. Once the queue is filled, extended threads are created.

Here is the code in TPE, which has problem

tpe-problem

We have got a couple of workarounds:

Workaround #1: Tweaking the Pool Sizes

Set the corePoolSize and maximumPoolSize to the same value and set allowCoreThreadTimeOut to true.

Pros

  • No coding hack required.

Cons

  • There is no real caching of threads, as threads are getting created and terminated quite often.
  • There is no proper scalability.

Workaround #2: Override the Offer Method

  • Override the offer method of delegator TransferQueue and try to provide the task to one of the free worker threads. Return false if there are no waiting threads.
  • Implement a custom RejectedExecutionHandler to always add to the queue.

tpe-rejection-handler

Refer to this implementation for more detail.

Pros

  • TransferQueue ensures that threads are not unnecessarily created, and transfers the work directly to waiting queue.

Cons

  • Customized rejection handler cannot be used, since it is used to insert the the tasks to queue.

Workaround #3: Use a Custom Queue

Use a custom queue (TransferQueue) and override the offer method to do the following:

  1. Try to transfer the task directly to a waiting queue (if any).
  2. If the above fails, and max pool size is not reached, then create an extended thread by returning false from the offer method.
  3. Otherwise, insert it into the queue.


tpe-refer-executor-in-queue

Refer to this implementation for more detail.

Pros

  • TransferQueue ensures that threads are not unnecessarily created and transfers the work directly to a waiting queue.
  • A custom rejection handler can be used.

Cons

  • There is a cyclic dependency between Queue and Executor.

Workaround #4: Use a Custom Thread Pool Executor

Use a Custom Thread pool executor specially dedicated for this purpose. It uses LIFO scheduling as described in Systems @ Facebook scale.

Thread pool Executor (software) Java (programming language)

Published at DZone with permission of Mohammad Nadeem, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Top 12 Technical Skills Every Software Tester Must Have
  • GitOps: Flux vs Argo CD
  • Using AI and Machine Learning To Create Software
  • ChatGPT — The Google Killer? The Job Taker? Or Just a Fancy Chatbot?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: