When I/O is the bottleneck of your application, more threads will increase the performance in opposite to when CPU is the bottleneck.
Stress Testing: Checking the throughput of an application by sending a huge amount of requests and examining the response times.
Isolate concurrent code by putting it in a few separate classes.
Always consider the concept of execution paths: The amount of possible interleaving of instructions that are processed by at least two threads. For example, objects with mutable states could unintentionally cause different results doing the same operation twice.
Atomic operation = operation which can not be interrupted by other threads. But for unsynchronized processes threads can put instructions between two atomic operations.
synchronized prevents unintended side-effects.
Server-based locking is preferred over client-based locking.
Server-based locking: The class used takes care of internal locking, so the user has nothing else to worry about.
Client-based locking: User has to manually implement locking. This approach error prone and hard to maintain.
If there is no access to the server an adapter class can be used instead. Even better would be thread-save collections using extended interfaces.
As little synchronized code (synchronized) as possible should be used. And if, then only for small, critical code sections.
Prevent Deadlocks
Do this by making one of its four conditions impossible.
Mutual Exclusion (Mutex)
Description:
When resources can't be used by mutual thread and
there are less resources than threads.
Solutions:
Use concurrently accessible resources like AtomicInteger.
Increase the number of resources until its greater or equal to the number of competing threads.
Check if every required resource is accessible before the task starts.
Lock & Wait
Description:
Once a thread acquires a resource, it will not release the resource until it has acquired all of the other resources it requires and has completed its work.
Solutions:
Before reservation of a resource, check its accessibility.
If a resource is not accessible, release every resource and start from anew.
Dangers:
Starvation: A thread never achieves to reserve all required resources.
Livelock: Thread gets tangled up.→ This approach is always applicable but inefficient as it causes a bad performance.
No preemption
Description:
A thread is unable to steal a resources reserved by another thread.
Solution:
A thread is allowed to ask another thread to release all of its resources (including the required one) and starting from anew. This approach is similar to the 'Lock & Wait' solution but has a better performance.
Circular Waiting / Deadly Embrace
Description:
When two or more threads require a resource which is already reserved by another of these threads.
Example:
Thread T1 has resource R1 and waits for R2 to be released.
Thread T2 has resource R2 and waits for R1 to be released.
Solution:
All threads reserve all resources in a the same order.
Problems:
The order of reservation doesn't necessarily have to be the same as the order of usage. This leads to inefficiencies like reserving a resource at the beginning which is just required at the end of the task.
Unnecessarily long locked resources.
Order can not always be specified.
Problems of testing multi-threaded methods
Very tricky which is why concurrency should be avoided in the first place.
In general this requires a lot of iteration which makes it resource intensive.
The outcome is architecture dependent (OS, hardware) which introduced randomness and make the error detection unreliable.
Solution approaches for testing multi-threaded methods
Monte-Carlo-Tests
Write flexible, adaptive tests.
Repeatedly run them on a test server and randomly vary the test settings.
If something fails, the code is defect and the applied settings should be logged.
Do this early to gain tests ASAP for your testing repertoire or CI-server.
Execute these tests on every platform over a long time to increase the probability that
the production code is correct or
the test code is bad.
Execute the tests on a computer using simulations of application loads when possible.
There are tools to test thread-based code like ConTest.
