一 调整 虚拟机参数 二 立即 释放无用的对象 三 利用序列化和反序列化技术 简单的说java中的堆和栈
java把内存分两种:一种是栈内存，另一种是堆内存
1。在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配; 2。堆内存用来存放由new创建的对象和数组
那些情况可以导致java内存溢出 数据量过于庞大 死循环
静态变量和静态方法过多
无法确定是否被引用的对象，java虚拟机不回收内存(内存泄漏)，循环产生过多重复的对象实体
线程池为线程生命周期开销问题和资源不足问题提供了解决方案。通过对多个任务重用线程，线程创建的开销被分摊到了多个任务上。其好处是，因为在请求到达时线程已经存在，所以无意中也消除了线程创建所带来的延迟。这样，就可以立即为请求服务，使应用程序响应更快。而且，通过适当地调整线程池中的线程数目，也就是当请求的数目超过某个阈值时，就强制其它任何新到的请求一直等待，直到获得一个线程来处理为止，从而可以防止资源不足
pageContext，request，session，application生命周期 request是封装client端(也就是用户通过browser)提交的请求数据和属性的对象。 response是封装web server端响应数据和属性的对象。
我们经常会将pageContext、request、session和application混为一谈，因为它们都可以通过setAttribute()和getAttribute()来设定或读取属性。但它们之间是有别的，它们最大的区别在于使用范围。
pageContext对象的范围只适用于当前页面范围，即超过这个页面就不能够使用了。所以使用pageContext对象向其它页面传递参数是不可能的。
request对象的范围是指在一JSP网页发出请求到另一个JSP网页之间，随后这个属性就失效。
session的作用范围为一段用户持续和服务器所连接的时间，但与服务器断线后，这个属性就无效。比如断网或者关闭浏览器。
application的范围在服务器一开始执行服务，到服务器关闭为止。它的范围最大，生存周期最长。
session主要功能:验证用户是否登录。在几个页面上都能取得。 request:只有 设置过多application 或每一个session保存过多的对象则性能降低 能使用request 就不要使用session 能使用session的就不要使用application application应用:在线人员统计、在线人员名单列表 pageContext:默认情况下一个页面的保存范围 实际上四种属性范围都是通过pageContext属性完成的 pageContext.setAttribute(\"name\更改红字的名字得到。 在另外一页用request去接收String name=(String)request.getAttribute(\"name\");<%=name%>; 如果要释放application资源要重新启动服务器 四种属性范围都是依靠pageContext展开的，但是在开发中，往往使用session和request范围最多。 JMS 如果用过JMS的话，会发现它类似写JDBC或JCA代码。它有创建或检索JMS资源的样板代码，每当你需要编写一个新类来发送或接受消息时，都得重复编写那个样本代码。下面列出了传统JMS实现涉及的步骤: 1、创建JNDI初始上下文context; 2、从JNDI上下文获得队列连接工厂; 3、从队列连接工厂取得队列Queue; 4、创建一个Session对象; 5、创建一个发送或接受对象; 6、利用第5部创建的发送或接受对象发送或接受消息; 7、处理完消息后，关闭所有JMS资源。 Hibernate缓存机制以及一级缓存和二级缓存的作用 Hibernate的缓存机制概念: java对象的属性(通常是一些集合类型的属性)占用的内存空间。如果对象的占用的内存很大就称为重量级的对象。如果对象的内存小就称为轻量级的对象。 Session 的缓存被称为hibernate的第一级缓存。SessionFactory的外置缓存称为hibernate 的二级缓存。这两个缓存都位于持久层，它们存放的都是数据库数据的拷贝。SessionFactory的内置缓存 存放元数据和预定义SQL, SessionFactory的内置缓存是只读缓存。 Session 缓存的三大作用: 1，减少数据库的访问频率，提高访问性能。 2，保证缓存中的对象与数据库同步，位于缓存中的对象称为持久化对象。 3，当持久化对象之间存在关联时，Session 保证不出现对象图的死锁。 Session 如何判断持久化对象的状态的改变呢, Session 加载对象后会为对象值类型的属性复制一份快照。当Session 清理缓存时，比较当前对象和它的快照就可以知道那些属性发生了变化。 Session 什么时候清理缓存, 1，commit() 方法被调用时 2，查询时会清理缓存，保证查询结果能反映对象的最新状态。 3，显示的调用session 的 flush方法。 session 清理缓存的特例: 当对象使用 native 生成器 时 会立刻清理缓存向数据库中插入记录。 hibernate一级缓存和二级缓存的区别 Hibernate提供了两级缓存，第一级是Session的缓存。由于Session对象的生命周期通常对应一个数据库事务或者一个应用事务，因此它的缓存是事务范围的缓存。第一级缓存是必需的，不允许而且事实上也无法比卸除。在第一级缓存中，持久化类的每个实例都具有唯一的OID。 第二级缓存是一个可插拔的的缓存插件，它是由SessionFactory负责管理。由于SessionFactory对象的生命周期和应用程序的整个过程对应，因此第二级缓存是进程范围或者集群范围的缓存。这个缓存中存放的对象的松散数据。第二级对象有可能出现并发问题，因此需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别。缓存适配器用于把具体的缓存实现软件与Hibernate集成。第二级缓存是可选的，可以在每个类或每个集合的粒度上配置第二级缓存。 Hibernate的二级缓存策略的一般过程如下: 1) 条件查询的时候，总是发出一条select * from table_name where „. (选择所有字段)这样的SQL语句查询数据库，一次获得所有的数据对象。 2) 把获得的所有数据对象根据ID放入到第二级缓存中。 3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查;查不到，如果配置了二级缓存，那么从二级缓存中查;查不到，再查询数据库，把结果按照ID放入到缓存。 4) 删除、更新、增加数据的时候，同时更新缓存。 Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query缓存。 Hibernate的Query缓存策略的过程如下: 1) Hibernate首先根据这些信息组成一个Query Key，Query Key包括条件查询的请求一般信息:SQL, SQL需要的参数，记录范围(起始位置rowStart，最大记录个数maxRows)，等。 2) Hibernate根据这个Query Key到Query缓存中查找对应的结果列表。如果存在，那么返回这个结果列表;如果不存在，查询数据库，获取结果列表，把整个结果列表根据Query Key放入到Query缓存中。 3) Query Key中的SQL涉及到一些表名，如果这些表的任何数据发生修改、删除、增加等操作，这些相关的Query Key都要从缓存中清空。 1 什么是单点登陆 单点登录(Single Sign On)，简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。 单点登录的机制也一样，如下图所示，当用户第一次访问应用系统1的时候，因为还没有登录，会被引导到认证系统中进行登录(1);根据用户提供的登录信息， 认证系统进行身份效验，如果通过效验，应该返回给用户一个认证的凭 据,,ticket(2);用户再访问别的应用的时候(3，5)就会将这个ticket 带上，作为自己认证的凭据，应用系统接受到请求之后会把ticket送到认证系统进行效验，检查ticket的合法性(4，6)。如果通过效验，用户就可 以在不用再次登录的情况下访问应用系统2和应用系统3了。 所有应用系统共享一个身份认证系统。 统一的认证系统是SSO的前提之一。认证系统的主要功能是将用户的登录信息和用户信息库相比较，对用户进行登录认证;认证成功后，认证系统应该生成统一的认证标志(ticket)，返还给用户。另外，认证系统还应该对ticket进行效验，判断其有效性。 所有应用系统能够识别和提取ticket信息 要实现SSO的功能，让用户只登录一次，就必须让应用系统能够识别已经登录过的用户。应用系统应该能对ticket进行识别和提取，通过与认证系统的通讯，能自动判断当前用户是否登录过，从而完成单点登录的功能。 接口和抽象类的区别 区别一，两者表达的概念不一样。抽象类是一类事物的高度聚合，那么对于继承抽象类的子类来说，对于抽象类来说，属于“是”的关系;而接口是定义行为规范，因此对于实现接口的子类来说，相对于接口来说，是“行为需要按照接口来完成”。 区别二，抽象类在定义类型方法的时候，可以给出方法的实现部分，也可以不给出;而对于接口来说，其中所定义的方法都不能给出实现部分。 区别三，继承类对于两者所涉及方法的实现是不同的。继承类对于抽象类所定义的抽象方法，可以不用重写，也就是说，可以延用抽象类的方法;而对于接口类所定义的方法或者属性来说，在继承类中必须要给出相应的方法和属性实现。 区别四，在抽象类中，新增一个方法的话，继承类中可以不用作任何处理;而对于接口来说，则需要修改继承类，提供新定义的方法。 如下给出两者的简单对比表格。 接口 抽象类 多继承 支持 不支持 类型限制 没有 有，只能是引用类型 方法实现 继承类型中必须给出方法实现 继承类中可以不给出 扩展性 比较麻烦 相对比较灵活 多层继承 比较麻烦，需要借助虚函数 比较灵活 笼统点说: 接口 = 定义了要做的所有事情，但自己啥也不干 抽象类 = 做了部分工作，剩下的他不干了，等后来人继续完成 3.2 内存泄漏示例 3.2.1 示例1 在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。 Vector v = new Vector(10); for (int i = 1; i<100; i++) {Object o = new Object(); v.add(o); o = null; }// 此时，所有的Object 对象都没有被释放，因为变量v 引用这些对象。实际上无用，而还被引用的对象，GC 就无能为力了(事实上GC 认为它还有用)，这一点是导致内存泄漏最重要的原因。 (1)如果要释放对象，就必须使其的引用记数为0，只有那些不再被引用的对象才能被释放，这个原理很简单，但是很重要，是导致内存泄漏的基本原因，也是解决内存泄漏方法的宗旨; (2)程序员无须管理对象空间具体的分配和释放过程，但必须要关注被释放对象的引用记数是否为0; (3)一个对象可能被其他对象引用的过程的几种: a.直接赋值，如上例中的A.a = E; b.通过参数传递，例如public void addObject(Object E); c.其它一些情况如系统调用等。 3.3 容易引起内存泄漏的几大原因 3.3.1 静态集合类 像HashMap、Vector 等静态集合类的使用最容易引起内存泄漏，因为这些静态变量的生命周期与应用程序一致，如示例1，如果该Vector 是静态的，那么它将一直存在，而其中所有的Object对象也不能被释放，因为它们也将一直被该Vector 引用着。 3.3.2 监听器 在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但 往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。 3.3.3 物理连接 一些物理连接，比如数据库连接和网络连接，除非其显式的关闭了连接，否则是不会自动被GC 回收的。Java 数据库连接一般用DataSource.getConnection()来创建，当不再使用时必须用Close()方法来释放，因为这些连接是独立于JVM的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象(关闭其中一个，另外一个也会关闭)，否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。 STRUTS,SPRING,HIBERNATE优缺点 1.struts struts框架具有组件的模块化，灵活性和重用性的优点，同时简化了基于MVC的web应用程序的开发。 优点: Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。 除此之外，Struts的优点主要集中体现在两个方面:Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。 关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统 各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。 另外，struts是业界\"标准\"(很多成功案例)，学习资源丰富，HTML标签非常优秀 缺点: Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。 Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。 ActionForms使用不便、无法进行单元测试(StrutsTestCase只能用于集成) 【IT168技术文档】 Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。 Struts开放源码框架的创建是为了使开发者在构建基于Java Servlet和JavaServer Pages(JSP)技术的Web应用时更加容易。Struts框架为开放者提供了一个统一的标准框架，通过使用Struts作为基础，开发者能够更专注于应用程序的商业逻辑。Struts框架本身是使用Java Servlet和JavaServer Pages技术的一种Model-View-Controller(MVC)实现. 具体来讲,Struts的优点有: 1. 实现MVC模式，结构清晰,使开发者只关注业务逻辑的实现. 2. 有丰富的tag可以用 ,Struts的标记库(Taglib)，如能灵活动用，则能大大提高开发效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。 3. 页面导航.页面导航将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于 后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。 4. 提供Exception处理机制 . 5. 数据库链接池管理 6. 支持I18N 缺点: 一、 转到展示层时，需要配置forward，每一次转到展示层，相信大多数都是直接转到jsp，而涉及到转向，需要配置forward，如果有十个展示层的jsp，需要配置十次struts，而且还不包括有时候目录、文件变更，需要重新修改forward，注意，每次修改配置之后，要求重新部署整个项目，而tomcate这样的服务器，还必须重新启动服务器，如果业务变更复杂频繁的系统，这样的操作简单不可想象。现在就是这样，几十上百个人同时在线使用我们的系统，大家可以想象一下，我的烦恼有多大。 二、 Struts 的Action必需是thread,safe方式，它仅仅允许一个实例去处理所有的请求。所以action用到的所有的资源都必需统一同步，这个就引起了线程安全的问题。 三、 测试不方便. Struts的每个Action都同Web层耦合在一起，这样它的测试依赖于Web容器，单元测试也很难实现。不过有一个Junit的扩展工具Struts TestCase可以实现它的单元测试。 四、 类型的转换. Struts的FormBean把所有的数据都作为String类型，它可以使用工具Commons-Beanutils进行类型转化。但它的转化都是在Class级别，而且转化的类型是不可配置的。类型转化时的错误信息返回给用户也是非常困难的。 五、 对Servlet的依赖性过强. Struts处理Action时必需要依赖ServletRequest 和ServletResponse，所有它摆脱不了Servlet容器。 六、 前端表达式语言方面.Struts集成了JSTL，所以它主要使用JSTL的表达式语言来获取数据。可是JSTL的表达式语言在Collection和索引属性方面处理显得很弱。 七、 对Action执行的控制困难. Struts创建一个Action，如果想控制它的执行顺序将会非常困难。甚至你要重新去写Servlet来实现你的这个功能需求。 八、 对Action 执行前和后的处理. Struts处理Action的时候是基于class的hierarchies，很难在action处理前和后进行操作。 九、 对事件支持不够. 在struts中，实际是一个表单Form对应一个Action类(或DispatchAction)，换一句话说:在Struts中实际是一个表单只能对应一个事件，struts这种事件方式称为application event，application event和component event相比是一种粗粒度的事件。 Struts重要的表单对象ActionForm是一种对象，它代表了一种应用，这个对象中至少包含几个字段，这些字段是Jsp页面表单中的input字段，因为一个表单对应一个事件，所以，当我们需要将事件粒度细化到表单中这些字段时，也就是说，一个字段对应一个事件时，单纯使用Struts就不太可能，当然通过结合JavaScript也是可以转弯实现的。 2(Hibernate Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序实用，也可以在Servlet/JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用EJB的J2EE架构中取代CMP，完成数据持久化的重任。 大多数开发机构经常采取创建各自独立的数据持久层。一旦底层的数据结构发生改变，那么修改应用的其余部分使之适应这种改变的代价将是十分巨大的。Hibernate适时的填补了这一空白，它为Java应用提供了一个易用的、高效率的对象关系映射框架。hibernate是个轻量级的持久性框架，功能却非常丰富。 优点: a. Hibernate 使用 Java 反射机制 而不是字节码增强程序来实现透明性。 b.Hibernate 的性能非常好，因为它是个轻量级框架。 映射的灵活性很出色。 c.它支持各种关系数据库，从一对一到多对多的各种复杂关系。 缺点: 它限制您所使用的对象模型。(例如，一个持久性类不能映射到多个表)其独有的界面和可怜的市场份额也让人不安，尽管如此，Hibernate 还是以其强大的发展动力减轻了这些风险。其他的开源持久性框架也有一些，不过都没有 Hibernate 这样有市场冲击力。 上面回贴情绪有点激动，希望谅解，我不是因为有人批评Hibernate而感到不快，而是因为帖子里面的观点实在让我觉得荒谬。不管觉得Hibernate好也吧，不好也吧，我唯一觉得遗憾的是，在中文论坛里面找不到一个对Hibernate的真正高水平的评价。在TSS上有一个关于Hibernate的hot thread，跟了几百贴，其中包括Hibernate作者Gavin和LiDO JDO的CTO，对于JDO和Hibernate有过一些激烈的争论，我曾经耐心的看了一遍，仍然没有发现针对Hibernate真正有力的攻击，那些所谓的攻击无非针对Hibernate没有一个GUI的配置工具，没有商业公司支持，没有标准化等等这些站不住脚的理由。 补充几点我的意见: 一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC 可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问 数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。 二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。 三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构: 传统的架构: 1) Session Bean <-> Entity Bean <-> DB 为了解决性能障碍的替代架构: 2) Session Bean <-> DAO <-> JDBC <-> DB 使用Hibernate来提高上面架构的开发效率的架构: 3) Session Bean <-> DAO <-> Hibernate <-> DB 就上面3个架构来分析: 1、内存消耗:采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。 2、运行效率:如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要 的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。 3、开发效率:在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。 4、分布式，安全检查，集群，负载均衡的支持 由于有SB做为Facade，3个架构没有区别。 四、EB和Hibernate学习难度在哪里, EB的难度在哪里,不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。 Hibernate难在哪里,不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在 Hibernate太灵活了。 当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。 Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢,这些方案之间到底有什么区别呢,他们的运行原理有什么不同,运行效率哪个比较好,光是主键生成，就有七八种方案供你选择，你为难不为难,集合属性可以用Set，可以用List，还可以用 Bag，到底哪个效率高，你为难不为难,查询可以用iterator，可以用list，哪个好，有什么区别,你为难不为难,复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些,你为难不为难,对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难, 这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢,还是悲哀呢,如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。 3( Spring 它是一个开源的项目，而且目前非常活跃;它基于IoC(Inversion of Control，反向控制)和AOP的构架多层j2ee系统的框架，但它不强迫你必须在每一层 中必须使用Spring，因为它模块化的很好，允许你根据自己的需要选择使用它的某一个模块;它实现了很优雅的MVC，对不同的数据访问技术提供了统一的 接口，采用IoC使得可以很容易的实现bean的装配，提供了简洁的AOP并据此实现Transcation Managment，等等 优点 a. Spring能有效地组织你的中间层对象，不管你是否选择使用了EJB。如果你仅仅使用了Struts或其他为J2EE的 API特制的framework，Spring致力于解决剩下的问题。 b. Spring能消除在许多工程中常见的对Singleton的过多使 用。根据我的经验，这是一个很大的问题，它降低了系统的可测试性和面向对象的程度。 c. 通过一种在不同应用程序和项目间一致的方法来处理配置文件，Spring能消除各种各样自定义格式的属性文件的需要。曾经对某个类要寻找的是哪个魔法般的属性项或系统属性感到不解，为此不得不去读Javadoc甚至源编码,有了Spring，你仅仅需要看看类的JavaBean属性。Inversion of Control的使用(在下面讨论)帮助完成了这种简化。 d.通过把对接口编程而不是对类编程的代价几乎减少到没有，Spring能够促进养成好的编程习惯。 e. Spring被设计为让使用它创建的应用尽可能少的依赖于他的APIs。在Spring应用中的大多数业务对象没有依赖于Spring。 f. 使用Spring构建的应用程序易于单元测试。 g. Spring能使EJB的使用成为一个实现选择,而不是应用架构的必然选择。你能选择用POJOs或local EJBs来实现业务接口，却不会影响调用代码。 h. Spring帮助你解决许多问题而无需使用EJB。Spring能提供一种EJB的替换物，它们适用于许多web应用。例如，Spring能使用AOP提供声明性事务管理而不通过EJB容器，如果你仅仅需要与单个数据库打交道，甚至不需要一个JTA实现。 i. Spring为数据存取提供了一个一致的框架,不论是使用的是JDBC还是O/R mapping产品(如Hibernate)。 Spring确实使你能通过最简单可行的解决办法来解决你的问题。而这是有有很大价值的。 缺点:使用人数不多、jsp中要写很多代码、控制器过于灵活，缺少一个公用控制器 因篇幅问题不能全部显示，请点此查看更多更全内容