'This is because Java stops to collect garbage from application transactions'

Later versions of the suns java vm does support other garbage collect models, like the mostly concurrent mark-sweep collector where gc:ing does not interrupt the execution of the vm.

If you need (hard) real-time, don't use dynamic memory management but preallocate all the required memory for the task. This is true for Java as much as it is for C/C++. In addition, a well designed garbage collector can have more predictable behavior (delay and jitter) than conventional memory management using malloc/free. Doing hard real-time with Java is just as difficult as it is with C/C++.

Time to face the facts. 10mS is enough time to execute 1,000,000 instructions on a modern processor. That's a million. You know 1e6! That doesn't include the 1000+ cycle best-case nap in the allocator, or multithreaded heap contention. In C++ you can control these things when you need to. In Java, no way. Java will never, can never meet the performance of C++ on apps that have to run flat out. In fact, when Java is only 10x slower, that's considered an impressive feat. Now that processors aren't getting faster anymore, the speed disadvantage is locked in.

It must be embarrassing to use a language with such obvious training wheels. Time to step up.