---

This time i am going to put the code first and try to explain later.

This code is used to instantiate the thread pool and process the pool of threads using the ArrayBlockingQueue. I prefer to use the ArrayBlockingQueue vs LinkedBlockingQueue. Every time an object is removed from the LinkedBlockingQueue you will have to mind the GC. Since this is a thread pool and can have a lot of fast to average threads running in them that means you can have extremely large amount of push and pop operations done over a period of time which is constant pressure on GC and also incur locks. Hence the use of ArrayBlockingQueue with small number of size is better. In ArrayBlockingQueue allocation of new memory for each add is prevented.

If using ArrayBlockingQueue, make sure how fast your thread is and how much you want to keep in queue at a given time and set the size accordingly. Whether you use Linked or Array Blocking queue if your queue is full then the thread pool executer blocks the running thread until the queue gets space to fill again.

If you are concerned about processing only the most recent amount of objects in the queue you can implement the Queue interface with the circular buffer and get away with not incurring the cost of array resize as well. If using circular buffer make sure the indexer you use is synchronized. The best of the three would be ArrayBlockingQueue with the occasional cost incurred for resizing.

You need to be careful while setting the size of a queue. The thread pool will be blocked until it gets space to push new threads inside. If we want the thread pool to run for ever with infinite amount of items in queue don't set the size.

The above code is a small snippet from my No-Sql solution which uses the thread to load all the files in parallel from disk based on their metadata. The metadata collection maintains the schema of all the tables or entities. The relationship between entities are part of the entities itself and not part of schema which makes querying and aggregation super easy.