[求助]高并发的大数据量查询导致系统频繁宕机,咋办啊

或者考虑是否适合预生成...

是很好，可需要DTO填充Collection，生成大对象显示到页面，还是建议使用报表工具，比如jasperreport。
另外，如果查询结果改动频率小，可以考虑查询缓存

打印不可以使用全部的数据吧？一页几十条也就足够了，如果有许多页的话可以考虑打印一页读一次请求一次。

导出的话，如果一下子导出很多的话，楼上楼上的预生成应该是个不错的办法。

业务的逻辑是什么？

预生成 和 分页打印都不太可行
业务比较特殊

简单点说吧

假设某省联通客户数有1000万
就一个业务 查询 导出 打印 详单(就是这个客户呼出或接收的所有的电话短信),时间段分别是入网至今所有的 本月 上月 或者历史上的某一月

打印是使用的那种 特殊的连打的打印机,就是不接受换页指令的 放入的纸是那种一个筒的

如果可以的再搞一个应用，专门负责打印功能，在was上同时部署这两个应用，两应用访问同一个db，打印的应用只读。

文件导出xls格式可以用分页的方式， 可以避免一次从数据库中查询出所有对象：

int pages = computePages();//查出页数
for(int i = 0; i < pages; i++){ //循环查询每页数据
    List records = findRecordByPageNo(i); //查询某页记录
    for(int j = 0; i < records.size(); i++){
        //写xls文件
    }
}

瓶颈在
写xls文件 那里
由于xls文件的特殊性 他必须要在内存中形成一个完整的对象 然后再输出

分页只解决了 大的collection问题 但是解决不了jxl的问题

呵呵，其实也就是要么你苦一点，在你这边尽量优化；要么让用户麻烦点，让他们做点事情，腾出时间来给你们！

文件不能追加吗？ 如果可以追加的话 还可以解决：创建文件关闭后 再打开追加数据
真要是必须一次创建完整文件的话 那就没什么招了

难道大对象都要一并的打印出来吗？
如果不是的话，我想还是要把大对象给单独提出来和你现有的表做个分割处理，毕竟大对象并不是大家所见既所得的东西，所以我的意见是把大对象单独做一个表来存储，可以和你现有的表做个一对一的关联而已，在不需要的时候并不需要带出来，这样可以很好的减轻服务端的负担