充分利用多核优势，高效并行渲染页面－－改造nutz使其成为支持并行计算的MVC框架

缓存 + 静态化

不是解决此类问题的主要途径么？

楼主可以做些数据出来对比下

楼上几位说的都是有道理的。
多线程并发处理这个功能不能烂用，是有场景的。
同时最好配合缓存一同使用。

这个怎么和并行计算扯上关系了?

他说的不是多线程吧  类似node.js 吧
再说一个页面顶多100个模块,也还没到过度异步吧

我觉得多线程，和多核没有什么关系吧
你这里应该是利用查询缓存

虽然实用还不靠谱...不过思路倒不错...

和CompletionService一起使用会更简洁和高效：

void solve(Executor e, Collection<Callable<Result>> solvers) throws InterruptedException, ExecutionException {
     CompletionService<Result> ecs = new ExecutorCompletionService<Result>(e);
     for (Callable<Result> s : solvers)
         ecs.submit(s);
     int n = solvers.size();
     for (int i = 0; i < n; ++i) {
         Result r = ecs.take().get();
         if (r != null)
             use(r);
     }
 }

楼主的思路是有用的，但是主要的应用场景不是这里，而是：
当需要启动多个耗时的操作时，不想一个一个等着他们串行去执行，想并行让他们尽快处理完，这时候用楼主的思路是合适的。

太不靠谱了，缓存、静态化、负载才是解决之道。楼主这样写，每个请求过来就要创建一个线程池，多个线程，如果有200的并发你试试。如果做成全局的线程池，你开多少个线程？多少都不够用，而且线程多了，cpu有要上下文切换的，那有的用户估计要超时了。多线程不是这么用的，一般用于后台任务或服务，比如通信、后台统计、调度等。楼主想法是好的，但应用场景不对，一般web请求不要用多线程，除非有特殊需求，比如一个请求过来后，要把这个请求转发或请求的一部分交给其他后台任务处理，这时可以分一个任务给一个线程

这种需求使用异步IO可能更加合适，线程有点重。