|
锁定老帖子 主题：SPRING的AOP不适合多线程应用？
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-10-14
真是伪命题中的伪命题,下面我举一些例子吧,内部原理就不说了(估计一两篇文章还说不完),
spring中代理对象本来就不带有线程可以随便修改的属性,也就是可以看成是无状态的,这也是spring的一个哲学,当然spring也提倡我们使用着也遵循这种原则,所以我们的service dao基本都是无状态的. 一个无状态的对象,任何线程都可以无限制的使用,哪里会产生什么效率问题呢,即使是有状态的对象,使用对象池或者每次都new一个,在一般的项目中也不会有问题啊,比如struts2.0,使用struts2.0的公司多了,每天几百w的访问量的也多的去了,怎么没见说有问题啊,我们就是使用struts2.0,活得很滋润 不要把不会用说成是框架不好. 我们这个pv 1亿多得网站新的web项目都是使用struts2.0,怎么没见有问题呢. ------------------------------------------- 我从来没有见过有项目是因为使用spring导致项目失败的,不知道能否有人拿出来让大家开开眼界 -------------------------------------------ps 大多数spring的项目都是web项目,都运行在web容器中,比如说tomcat,这不就是多线程的吗,每次请求都会从tomcat中的线程池拿一个线程出来处理这个请求,所以我们的spring基本上都运行在多线程的环境中 |
| 返回顶楼 | |
|
发表时间：2008-10-14
这是个伪命题。
线程安全性从来不是框架所能保证，并发编程的难点就是模块性的缺失，两个模块分开都是线程安全的，但是组合在一起你却不能说他一定是线程安全的。 因此指望spring帮你去解决代理对象的线程安全问题是不现实的，并发安全的保证只能来自于你的业务代码本身。 |
| 返回顶楼 | |
|
发表时间：2008-10-14
dennis_zane 写道 这是个伪命题。
线程安全性从来不是框架所能保证，并发编程的难点就是模块性的缺失，两个模块分开都是线程安全的，但是组合在一起你却不能说他一定是线程安全的。 因此指望spring帮你去解决代理对象的线程安全问题是不现实的，并发安全的保证只能来自于你的业务代码本身。 严重鄙视这些不仔细看问题的人，哈哈，猫是想说框架不是线程安全的，并发的构建代理对象，存在bug（而他说这个bug是不可修改的） |
| 返回顶楼 | |
|
发表时间：2008-10-14
nihongye 写道 dennis_zane 写道 这是个伪命题。
线程安全性从来不是框架所能保证，并发编程的难点就是模块性的缺失，两个模块分开都是线程安全的，但是组合在一起你却不能说他一定是线程安全的。 因此指望spring帮你去解决代理对象的线程安全问题是不现实的，并发安全的保证只能来自于你的业务代码本身。 严重鄙视这些不仔细看问题的人，哈哈，猫是想说框架不是线程安全的，并发的构建代理对象，存在bug（而他说这个bug是不可修改的） 我以为我理解了，照你这么说，我又理解错了？还是举例为妙 |
| 返回顶楼 | |
|
发表时间：2008-10-14
dennis_zane 写道 这是个伪命题。
线程安全性从来不是框架所能保证，并发编程的难点就是模块性的缺失，两个模块分开都是线程安全的，但是组合在一起你却不能说他一定是线程安全的。 因此指望spring帮你去解决代理对象的线程安全问题是不现实的，并发安全的保证只能来自于你的业务代码本身。 框架本身不是线程安全的你敢用吗？ 我这里说的就是框架本身不是线程安全，而不是程序员写程序造成的不安全。并不是要框架解决不安全的线程。 |
| 返回顶楼 | |
|
发表时间：2008-10-14
axeon 写道 支持tom猫,我也是来砸spring的。
我所理解的spring是相当低效率和无价值的，在我所经历和见到的spring项目中成功的少，垃圾的多。 一方面spring所倡导的概念仅仅是概念，缺乏实用性。小项目中太复杂，大项目用不上。使用spring之后，项目或产品的系统运维很麻烦，带来的好处倒是没觉得。 程序运行效率很重要，不可能因为机器便宜就可以盲目增加机器，一方面电力成本的问题，另一方面运维难度。 spring绝佳之处就在于概念，作为技术吹水的材料，spring是很适合的。 很有主见的说法，虽然很多人不认同。 事实上大公司还只是使用JSP+SERVLET，框架全部靠边站。 |
| 返回顶楼 | |
|
发表时间：2008-10-14
大猫汤姆 写道 dennis_zane 写道 这是个伪命题。
线程安全性从来不是框架所能保证，并发编程的难点就是模块性的缺失，两个模块分开都是线程安全的，但是组合在一起你却不能说他一定是线程安全的。 因此指望spring帮你去解决代理对象的线程安全问题是不现实的，并发安全的保证只能来自于你的业务代码本身。 框架本身不是线程安全的你敢用吗？ 我这里说的就是框架本身不是线程安全，而不是程序员写程序造成的不安全。并不是要框架解决不安全的线程。 嗯，我看明白了，比较迟钝：） 你所说的spring AOP返回的代理对象不是线程安全的。从spring实现来说这个选择是可以理解的，如你所说，要么同步要么new，整体带来的代价太高了。而对于目前的大部分基于数据库的crud的应用来说，DAO、service几乎都是无状态的，spring aop带来的好处显而易见。 |
| 返回顶楼 | |
|
发表时间：2008-10-14
阿里巴巴每天几亿PV，都是用的spring，你敢说它不适合大项目？！
|
| 返回顶楼 | |
|
发表时间：2008-10-14
dennis_zane 写道 大猫汤姆 写道 dennis_zane 写道 这是个伪命题。
线程安全性从来不是框架所能保证，并发编程的难点就是模块性的缺失，两个模块分开都是线程安全的，但是组合在一起你却不能说他一定是线程安全的。 因此指望spring帮你去解决代理对象的线程安全问题是不现实的，并发安全的保证只能来自于你的业务代码本身。 框架本身不是线程安全的你敢用吗？ 我这里说的就是框架本身不是线程安全，而不是程序员写程序造成的不安全。并不是要框架解决不安全的线程。 嗯，我看明白了，比较迟钝：） 你所说的spring AOP返回的代理对象不是线程安全的。从spring实现来说这个选择是可以理解的，如你所说，要么同步要么new，整体带来的代价太高了。而对于目前的大部分基于数据库的crud的应用来说，DAO、service几乎都是无状态的，spring aop带来的好处显而易见。 我的理解猫的意思是构建代理对象的过程是线程不安全的。不是说返回的代理对象是线程不安全的。但猫它还没给出证据。。。 |
| 返回顶楼 | |
|
发表时间：2008-10-15
nihongye 写道 我的理解猫的意思是构建代理对象的过程是线程不安全的。不是说返回的代理对象是线程不安全的。但猫它还没给出证据。。。 还是你细心.我就是这个意思. 不用给证据,看下AOP的源码就知道了. 我已经说得恶心了,从来没说这么多话.总之SPRING的源代码并不怎么样,不是说自己牛，SPRING给我的印像就是如此，IOC和AOP吹水的成份大.拿SPRING来吹水的人只会被鄙视。 很多人就是羊群心里重，听到有什么东西好都拥过去抢，捡了根鸡毛当宝贝，还不让别人说,自己喜欢的东西坚决反对别人指出缺点,这就是一个学霸的作为。 我也要吼一嗓子：“你们都是学霸”(不是的别往自己身上套，哈哈)! 
|
| 返回顶楼 | |
