解决方案 »

  1.   

    说不清楚spring为什么这么设计。但是连接池是由于消耗一定的资源,并且打开关闭数据库连接也是比较耗时的。如果打开的conn,没有正常关闭。那么会引起很多问题但是java 对象不一样,gc可以回收。
      

  2.   

    嗯,应该是没有必要用“池”,我在这里请教您一下另一个问题:
    系统里面有一个ExcelUtil来导出数据,由于这个系统使用每个月都集中在某一天几十个用户操作并导出数据,这样的话ExcelUtil单例好还是Prototype效果好?
    再有一个问题也是Excel的,我有另一个小系统里是管理员需要每次导出大约5K数据,现在虽然功能实现了,可是导出速度非常慢,需要个四五分钟吧,请问我需要在哪些方面需要注意和入手优化一下呢?
      

  3.   

    我觉得主要是因为Spring不是gc,没法知道对象是否还被引用。如果像scope为request/session之类的我倒是觉得也许可以被管理,虽然也不知道引用但是程序中声明过了生命周期。(下次找个机会测试下Spring)
    像EJB下可以@Remove标注一个方法通过调用该方法显式向容器声明生命周期结束,我觉得这Spring也可以有一个
      

  4.   

    现在对象创建是很廉价的操作,如果对象初始化不费事,原则上不用对象池,因为对象池有诸多问题,譬如:对象容器的同步、对象存储久了会进入老年代,增加了潜在full gc的次数,再而导致程序吞吐量下降,得不偿失
      

  5.   

    谢谢指点,学习了。在很多地方也找到了类似的说法。但是不死心啊.. 翻文档。EJB的specs里有句话说SLSB是are typically pooled;Spring里也找了下也是支持对象池的:Using TargetSources,同时有这么一句话:
    Although the cost of creating a new object isn’t high in a modern JVM, the cost of wiring up the new object (satisfying its IoC dependencies) may be more expensive.
    所以我还是坚持楼主说的这种情形可以用对象池见到大神顺便请教个过程中想到的问题:比如缓存管理会不会出现你说的进入老年代以及后续的影响呢?如果有的话在主流的库里都怎么做的?
      

  6.   

    嗯,应该是没有必要用“池”,我在这里请教您一下另一个问题:
    系统里面有一个ExcelUtil来导出数据,由于这个系统使用每个月都集中在某一天几十个用户操作并导出数据,这样的话ExcelUtil单例好还是Prototype效果好?
    再有一个问题也是Excel的,我有另一个小系统里是管理员需要每次导出大约5K数据,现在虽然功能实现了,可是导出速度非常慢,需要个四五分钟吧,请问我需要在哪些方面需要注意和入手优化一下呢?
    版主没有好的建议吗?还是觉得我是一个伸手党?