Moai World — Concurrency With Java Threading
I am reading Seven Concurrency Models in Seven Weeks: When Threads Unravel (The Pragmatic Programmers) recently. Reading without coding is a bit boring, therefore I created a playground called moai world to demo what I have learned from the book. If you are following my Github repositories, you will notice most of my repositories are modeled based on an interesting subject (e.g. moai-world models game Moai Kun, dr-spring models game Dr. Mario, gitlab-haile models a famous Marathon runner).
In chapter 2 (Threads and Locks) of the book, the author introduced the basic knowledge on the thread and lock in Java, he also presents a complete famous word count program on wiki data using Java threads. It’s really interesting to see that the author achieved 4 times speedup on a 4 core machine by using Thread to concurrent count the words.
At a fin-tech startup providing services to banks, we can’t avoid dealing with transactions. So I would like to apply what I learned to a toy problem:
How to summarize transactions in a concurrent way using Java thread?
When should we use Java thread?
Before we jump to the answer, let me explain to you about the domain and the design of the program first.
Our domain model is very simple as below:
Each transaction will have an unique id, it will record transaction time, amount, type (payment/refund), customer name, and merchant name. And if the transaction type is refund, it will have a linked transaction id from the original transaction.
Even though this is a toy model, you can gather a lot of information out of it. For example, we can query out merchant revenue during a certain time period. We can also find out the refund rate for a certain customer during a certain time period and so on. To avoid putting too much business logic into our toy problem, we will choose the following 2 summaries we want to know from the transaction:
- Total revenue a merchant earn from the transactions
- Total money a customer spends on the transactions
The program design is to go from no threading to multithreading. First, we implement the logic on how to calculate the summary based on a single full list of transactions. After that, we implement the logic on how we can merge multiple summary results into one result. Once we have all the building blocks, the final step is to split the large list into multiple small lists for summary and do the final merge after each Java thread finishes its job.
The complete program is in the moai-world Github repository, you can browse it to find out the answer for question 1. To answer question 2, I have done a bit more on performance testing. I picked 2 interesting charts from the result as below:
You can see from the result that if you are choosing the wrong per thread size when you are splitting the full list, the threading approach may spend more time than a normal program without threading. Besides that, from all of the results, it seems like work stealing pool is the best choice as executor.
The complete performance testing result is here.
