防止工作缓慢接管线程池

Question

I have a system where currently every job has it's own Runnable class and I pre defined a fixed number of threads for every job.

My understanding is that it is a wrong practice, because:

1. You have to tailor the number of threads with respect to the machine running the process.
2. Each threads can only take one type of job.

Would you agree on that? (current solution is wrong)

---

So, I'd like to use something like Java's ThreadPool instead. I was conflicted with an argument claiming that by doing so, slow jobs will take over most of the thread pool , leaving no place to the other jobs. Whereas, with the current solution, a fixed number of threads were assigned to the slow worker and it won't hurt the others.

(Notice that you can't know a-priori if a job will be "slow")

---

How can a system be both adaptive in the number of threads it uses, but at the same time not be bounded to the most slow job?

Answer 1

You could try getting the time it takes for the job to complete (With a hand-made Timer class of sorts. Then you normalize this value by dividing this time by the maximum time any given thread has taken. Finally, you multiply this number by a fixed number which varies depending on how many threads you want running per job per second. This will be the requested amount of threads this process should be using. You can adjust that according.

Edit: You can set minimum and maximum values that regulate how many threads a job is entitled to. You could alternatively request threads from a very spacious job when another thread enters the system.

Hope that helps!

Answer 2

It's more of a business problem. Let's say I am a telecom operator. I bar my subscribers from making outgoing calls when they don't clear their dues. When they make payment I clear a flag and in a second the subscriber can make calls. But a lot of other activities go on in my system like usage processing, billing, bill formatting etc.

Now let's assume I have a system wide common pool of threads and I started the billing of 50K subscribers. All my threads are now processing the relatively long running billing jobs and a huge queue is building up.

A poor customer now makes a payment and wants to make an urgent call. But I have no thread left in my pool to clear the flag. The customer had to wait for an hour before he can make the call. That's SLA breach.

What I should have done is create separate thread pools. If the call unblocking jobs are not very frequent and short, I can create a separate pool for it with core size 5 maybe. For billing jobs I'd rather create a pool with core size 25 and max-size 30.

So, my system limits won't anyway exceed because I know in even the worst situation I won't have more than 30 threads.

This will also make it easy to debug. If I have a different thread name pattern for each pool amd my system has some issues. I can easily take a thread dump and understand if the billing or the payment stuff is the culprit.

So, I think the existing design is based on some business use case which you need to thoroughly understand before proposing a solution.