Manipulate Thread Implementation in JVM

Recently, I've been working on the deployment of concurrent objects onto multicore. In a sample, I use BlockingQue开发者_运维知识库ue.take() method whose specification mentions that it is blocking. It means that the method does not release the enclosing thread's resources such that it can be re-used for other concurrent tasks. This is useful since the total number of live threads in a JVM instance is limited and if the application would need thousands of live threads, then it is vital to be able to re-use suspended threads. On the other hand, JVM uses a 1:1 mapping from application-level threads to OS-level threads in Java; i.e. each Java Thread instance becomes an underlying OS-level thread.

The current solution is based on java.util.concurrency in Java 1.5+. Still, we need worker threads that are such scalable to a large number. Now, I am interested to find the following answers:

• Is there any way to replace the implementation of java.lang.Thread in JVM such that I can plug my own Thread implementation?
• Is this only possible through tweaking C++ sections of the thread implementation in JVM and recompiling it?
• Is there any library to provide a way to replace the classical thread in Java?
• Again, in the same line, is there a library or a way to guide how some threads in Java can be mapped to only one thread in the OS-level?

I also found this discussing different implementations of JVM and I am not sure if they could help.

Thanks for your comments and ideas in advance.

If you are creating thousands of threads, you're doing it wrong.

Instead, consider using the Executor framework. (Start with the Executors and ThreadPoolExecutor classes.) They allow you to queue thousands of tasks while having a sane number of threads handling them.

I guess this approach is what you meant by "library to replace the classical threads". I highly recommend you look into executors.

One caveat: Executors, by default, use non-daemon threads. Therefore, you must shut down your executor when you're done with it. You can do this at program exit, if there is a normal way to exit your program that doesn't simply involve waiting for all threads to finish. :-)