<context:component-scan base-package="com.blog">
<context:include-filter type="regex"
expression="com\.blog\.service\..*"/>
<context:exclude-filter type="aspectj"
expression="com.blog.util..*"/>
</context:component-scan>
4.1注释配置不一定在先天上优?XML 配置。如?Bean 的依赖关pL固定的,Q如 Service 使用了哪几个 DAO c)Q这U配|信息不会在部v时发生调_那么注释配置优于 XML 配置Q反之如果这U依赖关pM在部|时发生调整QXML 配置昄又优于注释配|,因ؓ注释是对 Java 源代码的调整Q您需要重新改写源代码q新编译才可以实施调整?br />
4.2如果 Bean 不是自己~写的类Q如 JdbcTemplate、SessionFactoryBean {)Q注释配|将无法实施Q此?XML 配置是唯一可用的方式?br />
4.3注释配置往往是类U别的,?XML 配置则可以表现得更加灉|。比如相比于 @Transaction 事务注释Q?aop/tx 命名I间的事务配|更加灵zd单?br />
4.4所以在实现应用中,我们往往需要同时用注释配|和 XML 配置Q?strong>对于cȝ别且不会发生变动的配|可以优先考虑注释配置Q?strong>而对于那些第三方cM及容易发生调整的配置则应优先考虑使用 XML 配置?br />
参考资料:
http://kdboy.javaeye.com/blog/419159
http://www.ibm.com/developerworks/cn/java/j-lo-spring25-ioc/
每一?2位的q程最多可以?G的可用内存,因ؓ另外2G被操作系l保留。这里假设?.5GlJVMQ那么还余下500M可用内存。这500M内存中的一部分必须用于pȝdll的加载,那么真正剩下的也许只?00MQ现在关键的地方出现了:当你使用Java创徏一个线E,在JVM的内存里也会创徏一个Thread对象Q但是同时也会在操作pȝ里创Z个真正的物理U程(参考JVM规范)Q操作系l会在余下的400兆内存里创徏q个物理U程Q而不是在JVM?500M的内存堆里创建。在jdk1.4里头Q默认的栈大是256KBQ但是在jdk1.5里头Q默认的栈大ؓ1M每线E,因此Q在余下400M的可用内存里Ҏ们最多也只能创徏400个可用线E?/p>
q样l论出来了Q要惛_建更多的U程Q你必须减少分配lJVM的最大内存。还有一U做法是让JVM宿主在你的JNI代码里边?/p>
l出一个有兌够创建线E的最大个数的估算公式Q?/p>
(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads
对于jdk1.5而言Q假设操作系l保?20M内存Q?br />
1.5GB JVM: (2GB-1.5Gb-120MB)/(1MB) = ~380 threads
1.0GB JVM: (2GB-1.0Gb-120MB)/(1MB) = ~880 threads
?000/XP/2003的boot.ini里头有一个启动选项Q好像是Q?font color="#339966">/PAE /3G Q可以让用户q程最大内存扩充至3GQ这时操作系l只能占用最?G的虚存。那样应该可以让JVM创徏更多的线E?br />
因此q种情况需要结合操作系l进行相兌整?br />
因此Q我们需要结合不同情况对tomcat内存分配q行不同的诊断才能从Ҏ上解决问题?br />
参考资料(从这些资料中受益良多Q:
http://www.javaeye.com/topic/80620?page=1
http://ggmm.blog.sohu.com/117545379.html
http://hi.baidu.com/hexiong/blog/item/16dc9e518fb10c2542a75b3c.html
http://www.wujianrong.com/archives/2006/12/javalangoutofmemoryerror_permg.html