What is a threadpool executor

Imagine you have a web application which processes a lot of requests. The requests could vary from fetching a file to inserting or recording values in a database. Assuming you have around a hundred requests calling your application in one second. In this scenario a likely design would be to spawn a thread for each incoming request which will execute the implementation logic.
However, this approach is bound to create problems as the number of threads would increase geometrically when scaling and at the same time each thread has it's own resources. This means additional resources which have to wait to get garbage collected at the mercy of the JVM.
This is where a threadpool executor helps. Typically you assign a fixed number of threads that will be 'pooled'. When your application has an incoming request a thread is allocated, which then goes on and allocates the implementation to the code and returns back to the pool. This reduces the number of threads that we use in our application and thereby conserve resources. This architecture helps in keeping manageable the number of threads in a multithreaded application.

Guidelines for effective use of thread pools:

• Be careful when using pooled threads for potentially long-lived operations. If the program must wait for a resource, such as an I/O completion, specify a maximum wait time, and then fail or requeue the task for execution at a later time. This guarantees that eventually some progress will be made by freeing the thread for a task that might complete successfully.
  
  
• Understand your tasks. To tune the thread pool size effectively, you need to understand the tasks that are being queued and what they are doing. Are they CPU-bound? Are they I/O-bound? Your answers will affect how you tune your application. If you have different classes of tasks with radically different characteristics, it may make sense to have multiple work queues for different types of tasks, so each pool can be tuned accordingly.

Posted from Blogium for iPhone

Synchronized and instantiated

This was a question my manager put across to me when I was in some discussion with him:
We have a class A which has a synchronized method say abc(). Two instances a1 and a2 are created from A.
Now two threads t1 and t2 call the abc() method on a1 and a2 respectively. The question is:
Will the execution of abc() be synchronized?
My answer was no. This is because the scope of abc() is the object and not the class. Hence when the same method is called on different instances, their scope is restricted to that instance and execution continues. Had the threads been executing the method on the same object, abc() would have been synchronous.
The solution to this is to declare the method as static. This keeps the scope of the method at the class level and would behave synchronously across multiple instances.

Posted from Blogium for iPhone