Most of you already know about threads and it’s benefits. This article will help you to understand how thread are being used in real world applications and what are the best practices. Threads are primarily used to achieve asynchronous behavior and multitasking.
Below are some common real life use cases where threads have been used effectively.
- Animation and Games.
- Most of the GUI tools like Swing uses thread to keep track of events generated from widgets.
- Internally Junit uses threads for executing test cases parallel.
- Most of the web servers uses multithreading to entertain HTTP Requests parallel
Below are some common best practices for developing concurrent (multi threaded )applications.
Naming a Thread-
Thread should be named for easier debugging. You can see in Eclipse that threads running in parallel with some random names like “Thread-124362563”. Giving a unique name to a thread will make it easier to identify the thread while debugging.
How many threads-
Before deciding number of threads to create , please keep in mind following facts.
- One processor executes a thread at a time and keeps switching between threads. Too much of switching can be an inefficient solution.
- Now a days most of the computers are multi core i.e comes with multiple processor so multiple threads can be executed simultaneously.
For long running threads one practice can be to have no of processors as no of threads.
Use Immutable Classes
Immutable classes, once created cannot be modified so one does not need to worry about sharing the state with multiple threads. This reduces a great scope of synchronization.
Threads VS JMS –
I have developers discussing JMS VS Threads for developing asynchronous behavior. I think JMS is more controllable way to use threads. JMS gives you additional features like tracking of request and retry to make a better enterprise choice.
Use Executors instead of Threads API
Object pool is a concept to avoid cost of object creation and destruction. JDK provides “Executors” as managed thread pool.
Use java.util.concurrent
Java 5 added a java.util.concurrent to the Java. This package contains a set of classes that makes it easier to develop concurrent scalable applications .Before this package was added , one need to use “synchronized” , “volatile” , “join” , “wait” and “notify” to write concurrent ( multi threaded applications) .
Popular items of “java.util.concurrent” are “BlockingQueue” , “semaphore” , “Lock Interface” , “CountDown Latch” and “CyclicBarrier”.
Giving some details about Locks , CountDown Latch and Cyclic Barrier.
Locks
Prior to java 5 “synchronized” and “volatile” were the means of achieving concurrency. “Synchronized” provides a clean way to code but comes with limitation like try lock i.e. acquire only if lock is available. For more scalable concurrent solution JDK added lock interface and various implementations. “Reentrant lock” is a popular implementation of Lock interface.
Synchronized acquired a intrinitc lock on object wihis realeased automaticaaly. Bot with Lock , one need to release a lock programiticaaly. Best practice is to relase the lock in try block.
Synchronized acquired a intrinitc lock on object wihis realeased automaticaaly. Bot with Lock , one need to release a lock programiticaaly. Best practice is to relase the lock in try block.
CyclicBarrier and CountDown Latch
Both CyclicBarrier and CountDown latch are used for thread synchronization i.e. thread waits for another thread to complete their job at some point. Difference between both is that Cyclic Barrier instance can be reused while CountDownLatch instance can not.
Enterprise | Cloud | Microservices 