javaEE常见性能问题
Java性能优化【技巧】集锦
Java性能优化技巧集锦===================================提纲:===================================一、通用篇1.1 不用new关键词创建类的实例1.2 使用非阻塞 I/O1.3 慎用异常1.4 不要重复初始化变量1.5 尽量指定类的final修饰符1.6 尽量使用局部变量1.7 乘法和除法1.8 尽量重用对象。
二、J2EE篇2.1 使用缓冲标记2.2 始终通过会话Bean访问实体Bean2.3 选择合适的引用机制2.4 在部署描述器中设置只读属性2.5 缓冲对EJB Home的访问2.6 为EJB实现本地接口2.7 生成主键2.8 及时清除不再需要的会话2.9 在JSP页面中关闭无用的会话2.10 Servlet与存使用2.11 HTTP Keep-Alive2.12 JDBC与Unicode2.13 JDBC与I/O2.14 存数据库三、GUI篇3.1 用JAR压缩类文件3.2 提示Applet装入进程3.3 在画出图形之前预先装入它3.4 覆盖update方法3.5 延迟重画操作3.6 使用双缓冲区3.7 使用BufferedImage3.8 使用VolatileImage3.9 使用Window Blitting四、JavaScript性能优化1.使用局部变量避免使用全局变2.避免使用with3.遍历nodelist的方式4.别用那么多个var，一个加逗号就搞定了5.innerHTML是最好的选择6.ie的removeChild不好用7.为多个同级元素绑定事件时，不用为每个都绑定，为他们的父级绑定就行了8.尽量用原生的方法，因为原生的都是用c/c++编译而成的他们执行的要比用js写的方法快多了9.appendChild用的多时一定要用docuemntfragment10.if else用的>=3个了，那用switch吧，好阅读，性能好11.if<=3,别用if了，用3元表达式吧12.if==1，if改&&13.元素位置，while()offsetParent14.正则的查找没有indexOf快15.设置某个元素的style时用cssText简单些16.new 时,没有参数时函数名后边的括号可以去了五、其他===================================正文:===================================一、通用篇“通用篇”讨论的问题适合于大多数Java应用。
javaweb实训中遇到的问题与解决方法
javaweb实训中遇到的问题与解决方法Javaweb实训中遇到的问题与解决方法问题1：数据库连接问题•问题描述：在实训中，连接数据库是必不可少的步骤。
但是有时候会遇到连接失败的情况，无法进行数据库操作。
•解决方法：检查以下几个方面：–确保数据库服务已启动，检查数据库的用户名和密码是否正确；–检查数据库驱动是否正确导入，版本是否兼容；–检查连接字符串是否正确，包括数据库的地址、端口号、数据库名等；–检查防火墙是否阻止了数据库连接。
问题2：编码问题•问题描述：如果在实训中遇到乱码的情况，可能是由于编码设置不正确导致的。
•解决方法：考虑以下几个方面：–在数据库连接时，指定连接字符集（如utf8）；–在Javaweb项目中，设置请求和响应的字符集为utf-8；–在HTML页面中，使用<meta charset="utf-8">指定文档字符集；–在文件和数据库之间进行数据传输时，注意编码转换。
问题3：页面跳转问题•问题描述：在实训中，页面跳转是非常常见的操作。
但是有时候会遇到跳转失败或跳转逻辑不正确的问题。
•解决方法：考虑以下几个方面：–确保跳转的URL地址正确无误，并且对应的页面文件存在；–使用正确的跳转方式，如通过()实现重定向，或通过RequestDispatcher实现转发；–检查跳转逻辑的正确性，确保在合适的时机进行跳转。
问题4：文件上传问题•问题描述：在实训中，涉及到文件上传的功能，但是有时候会遇到上传失败或文件丢失的问题。
•解决方法：考虑以下几个方面：–检查文件上传的目录是否存在，并且有合适的读写权限；–检查表单中的enctype属性是否设置为multipart/form-data；–确保文件大小和类型的限制在合理范围内；–在代码中进行文件接收和保存的逻辑时，注意异常的处理和错误信息的及时反馈。
问题5：安全性问题•问题描述：在实训中，保护数据的安全性是非常重要的，避免出现数据泄露或被非法篡改的情况。
Java Web开发常见问题的解决方法
Java Web开发常见问题的解决方法Java Web开发是现在互联网领域中非常热门的技术方向，在大型公司和互联网企业中都有广泛应用。
然而，Java Web开发在实践中也会遇到一些问题，例如性能低下、内存泄漏、容器部署等等。
本文将对Java Web开发中一些常见问题进行分析，并给出解决方法。
一、性能低下的问题当用户面前的网站响应速度慢，不仅会降低用户的体验，也会影响网站的SEO排名。
因此，保证Java Web应用的性能是非常重要的。
1.合理使用缓存技术缓存技术是提高Java Web性能的重要手段之一。
Java Web应用的许多操作都是“读多写少”的操作，因此在读取频繁的数据时，Java Web应用可将这些数据缓存到内存中或者使用Redis、Memcached等缓存中间件进行提高反应速度。
2.编写高性能的代码编写高性能的Java Web应用，要求编写高效的程序代码，尽量减少创建对象的次数、缩短对象存储周期和阻塞IO等操作，这些都可以增加Web应用的极限吞吐量、提高响应速度。
3.JVM内存调优JVM对于Java Web应用的性能调优非常重要。
通过JVM的-Xmx、-Xms等配置参数调整JVM内存，避免应用因Java Virtual Machine的按需分配而产生的停顿和性能下降。
同时，也可以避免一些JVM垃圾回收性能等问题。
二、内存泄漏的问题内存泄漏是Java Web系统中常见的问题之一。
Java语言自带的垃圾回收机制可以自动回收不再使用的内存，但如果应用程序中存在不良内存释放的情况，就会出现内存泄漏的问题。
1.使用分析工具来检测内存泄漏在Java Web应用中，常用的内存泄漏分析工具有VisualVM和Eclipse Memory Analyzer等。
使用这些工具可以快速检测大量内存消耗的问题，有效分析应用程序的内存资源占用情况。
2.及时处理资源释放问题Java Web应用中还有很多资源需要释放和管理，例如数据库连接、文件读取等等。
J2EE应用程序现场实施常见问题汇总
J2EE应用程序现场实施常见问题汇总一、游标问题问题现象系统运行期间报出游标超出最大值错误（maximum open cursors exceeded），直接导致应用瘫痪，重启数据库服务器情况得到缓解，但运行一段时间后再次出现上述错误。
原因分析由于系统平台生成Sequence序列号的方法存在缺陷，造成数据库持续打开游标且无关闭操作，加之Oracle默认的每连接允许打开的游标最大数偏小，所以造成上述错误。
解决方法使用最新的已修正序列号问题的平台版本并修改ORACLE的配置文件，将OPEN_CURSORS参数设置为1000。
二、session问题问题现象群集环境在使用Weblogic自带的软件代理情况下，所有从Session中取回数据的操作随机性的报出空指针错误，造成页面无法显示，业务操作无法继续，重启Weblogic集群后，情况有所好转，但很快又出现上述错误。
原因分析由于Weblogic自带的软件代理算法上存在缺陷，造成同一业务内多步操作被分发到集群中不同的服务器，从而形成Session漂移。
由于我们自定义的JAVA类没有很好的处理序列化等相关内容，造成Session复制时出现错误，特别当在Session中存放DTO、ActionForm或集合等对象时现象尤其明显。
解决方法1. 不使用Weblogic集群，使用单域模式。
2. 使用硬件代理（如F5）。
3. 避免在代码中使用Session来保存DTO、ActionForm或集合等不宜序列化的对象。
三、表单乱码问题问题现象英文系统下提交表单数据到后台显示为乱码。
原因分析由于英文系统提交表单时使用的字符集编码为ISO8859-1，所有中文数据显示为乱码。
解决方法1.使用Spring 提供的转码过滤器，需要在web.xml 中增加以下配置：1 2 3 4 5 6 7 8 9 10 11 12<FILTER> <FILTER-NAME>Set Character Encoding</FILTER-NAME> <FILTER-CLASS>org.springframework.web.filter.CharacterEncodingFilter</FILTE R-CLASS> <INIT-PARAM> <PARAM-NAME>encoding</PARAM-NAME> <PARAM-VALUE>utf8</PARAM-VALUE> </INIT-PARAM> </FILTER> <FILTER-MAPPING> <FILTER-NAME>Set Character Encoding</FILTER-NAME> <URL-PATTERN>*.html</URL-PATTERN> </FILTER-MAPPING> 2.在提取表单数据前先执行以下命令：1 r equest.setCharacterEncoding("UTF-8");四、URL 乱码问题问题现象中文环境的操作系统（如windows ）下部署的系统，但Weblogic 为英文版，部分Jsp 页面出现中文乱码，导致保存至数据库的数据也是乱码，但回显旧数据时正常。
Java开发过程中遇到的问题及解决方法
Java开发过程中遇到的问题及解决⽅法1、SpringMVC前台提交参数绑定list时⼤⼩超过256 解决⽅案：①在使⽤该⽅法的类上添加⽅法修改默认长度 @InitBinde public void initBinder(WebDataBinder binder) { //长度根据实际情况修改 binder.setAutoGrowCollectionLimit(500); } ②在整个项⽬中使⽤ 定义⼀个初始化类public class myInitializer implements WebBindingInitializer { @Override public void initBinder(WebDataBinder binder) { binder.setAutoGrowCollectionLimit(100000); } } 然后在配置⽂件中配置 <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"> <property name="webBindingInitializer"> <bean class="xxx.myInitializer"/> //class指myInitializer类 </property> </bean>2、get⽅式请求后台时，由于参数中带有特殊字符&导致异常 前端传递参数时使⽤encodeURIComponent⽅法进⾏重新编码，后端因为spring默认会进⾏⼀次解码操作，所以可以直接获取。
3、使⽤hql语句对其中的⽇期属性和当前⽇期进⾏过滤时，直接使⽤new Date()导致的问题 可以先把当前⽇期转成字符串然后再进⾏过滤（配合Date和Calender类）4、sql语句处理分组的时候，在本地服务使⽤没问题，在服务器上出现sql异常 group by语句规范，本地安装的MySQL，对group by进⾏了泛化,⽽服务器是Linux，只会按照标准来执⾏。
10种java性能优化方案
你是否正打算优化hashCode()方法？是否想要绕开正则表达式？Lukas Eder介绍了很多简单方便的性能优化小贴士以及扩展程序性能的技巧。
最近“全网域（Web Scale）”一词被炒得火热，人们也正在通过扩展他们的应用程序架构来使他们的系统变得更加“全网域”。但是究竟什么是全网域？或者说如何确保全网域？ 扩展的不同方面
全网域被炒作的最多的是扩展负载（Scaling load），比如支持单个用户访问的系统也可以支持10 个、100个、甚至100万个用户访问。在理想情况下，我们的系统应该保持尽可能的“无状态化（stateless）”。即使必须存在状态，也可以在网络的不同处理终端上转化并进行传输。当负载成为瓶颈时候，可能就不会出现延迟。所以对于单个请求来说，耗费50到100毫秒也是可以接受的。这就是所谓的横向扩展（Scaling out）。
扩展在全网域优化中的表现则完全不同，比如确保成功处理一条数据的算法也可成功处理10条、100条甚至100万条数据。无论这种度量类型是是否可行，事件复杂度（大O符号）是最佳描述。延迟是性能扩展杀手。你会想尽办法将所有的运算处理在同一台机器上进行。这就是所谓的纵向扩展（Scaling up）。
如果天上能掉馅饼的话（当然这是不可能的），我们或许能把横向扩展和纵向扩展组合起来。但是，今天我们只打算介绍下面几条提升效率的简单方法。 大O符号
Java 7的 ForkJoinPool 和Java8 的并行数据流（parallel Stream） 都对并行处理有所帮助。当在多核处理器上部署Java程序时表现尤为明显，因所有的处理器都可以访问相同的内存。 所以，这种并行处理较之在跨网络的不同机器上进行扩展，根本的好处是几乎可以完全消除延迟。
但不要被并行处理的效果所迷惑！请谨记下面两点： 并行处理会吃光处理器资源。并行处理为批处理带来了极大的好处，但同时也是非同步服务器（如HTTP）的噩梦。有很多原因可以解释，为什么在过去的几十年中我们一直在使用单线程的Servlet模型。并行处理仅在纵向扩展时才能带来实际的好处。 并行处理对算法复杂度没有影响。如果你的算法的时间复杂度为 O(nlogn)，让算法在 c 个处理器上运行，事件复杂度仍然为 O(nlogn/c)， 因为 c 只是算法中的一个无关紧要的常量。你节省的仅仅是时钟时间（wall-clock time），实际的算法复杂度并没有降低。 降低算法复杂度毫无疑问是改善性能最行之有效的办法。比如对于一个 HashMap 实例的 lookup() 方法来说，事件复杂度 O(1) 或者空间复杂度 O(1) 是最快的。但这种情况往往是不可能的，更别提轻易地实现。
面向JavaEE Web应用系统的性能诊断策略
２ 性能诊 断策略
２１面 向用户 事务 的诊 断 ． 与 最 终 用 户 体 验 直 接 相 关 的 是 用 户 事 务 的 响 应 时 间 表 现 。用 户 事 务 主 要 针 对 业 务 而 言 ，１ 用 户 事 务 通 常 由 个 １ 或 一 系 列 的 用 户 操 作 组 成 。分 析 用 户 事 务 通 常 从 不 同 的 角 度 来 对 其 执 行 结 果 进 行 分 析 。 个 在 Ｌ ａＲ ｎ ｅ ｏ ｄ ｕ ｎｒ中有 ２种 和 事 务 相 关 的 概 念 ：Ａ ｔ ｎ和 Ｔ ａｓｃｉｎ ］ ｃｉ ｏ ｒｎａｔ 。Ａｃ ｏ ｏ ｔ ｎ是 用 户 的 一 系 列 操 作 的 组 合 ， ｉ Ｔ ａ ｓｃｉｎ是 用 户 某 一 具 体 的动 作 。Ａ ｔ ｎ通 常 会 包 含 一 系 列 功 能 相 关 的 Ｔａ ｓｃｉ 。在 测 试 过 程 中 ，事 务 往 往 ｒｎ ａｔ ｏ ｃｉ ｏ ｒｎａｔ ｎ ｏ 有 ３ 执 行 结 果 ： １ 通 过 （ ａｓ：按 照 预 定 计 划 执 行 了 全 部 虚 拟 用 户 脚 本 ；２ 失 败 （ ａ ） 种 ） Ｐ ｓ） ） Ｆ ｉ ：虚 拟 用 户 脚 本 执 行 过 ｌ
首先 ，以与最终用 户体验 直接 相关 的交 易 响应 时 间为起 点 ，面 向 用 户 事务 的 表 现 进 行 判 断 ，尽 可 能 锁 定 几 个 突 出 的 问题 ，基本确 立下一 步 的诊 断方 向 。然 后 ，通过 面 向资源瓶 颈 的诊 断 ，确 定性能 下降是 否属 系统资 源瓶颈造 成 的。继而
吐 量 、执 行 效 率 、资 源 占用 、稳 定 性 及 可 靠 性 等 方 面 的 问 题 。 基 于 这 种 复 杂 性 ，系 统 的 任 何 一 个 环 节 出 现 瓶 颈 ， 都 会 导 致 系 统 出 现 性 能 问 题 ，这 也 给 性 能 诊 断 带 来 了挑 战 ¨３ －。 １
J2EE开发工作中遇到的异常问题及解决方法总结
J2EE开发⼯作中遇到的异常问题及解决⽅法总结1. HttpClient I/O exception：错误信息：I/O exceptioncaught when processing request: Connection timed out:connect错误原因：IP不正确。
解决⽅法：改正IP2. Ambiguous handler methods mapped错误信息：ng.IllegalStateException: Ambiguoushandler methods mapped for HTTP path '/lowpressure.json'Ambiguous:模糊不清的，有歧义的错误原因：项⽬中存在两个相同的RequestMapping路径解决⽅法：修改其中⼀个名称3. session read-only错误信息：org.springframework.dao.InvalidDataAccessApiUsageException: Write operations are not allowed in read-only mode(FlushMode.NEVER/MANUAL): Turn your Session into MIT/AUTO orremove 'readOnly' marker from transaction definition.错误原因：开启了openSessionInViewFilter，⽽这种session的默认模式是只读。
解决⽅法：为其设置初始化参数singleSession=false。
<init-param><param-name>singleSession</param-name><param-value>false</param-value></init-param>4. org/hibernate/exception/DataException错误信息：javax.servlet.ServletException:ng.NoClassDefFoundError:org/hibernate/exception/DataExceptionCaused by: ng.NoClassDefFoundError:org/hibernate/exception/DataException错误原因：不明。
JavaEE5学习笔记13JSF集成Facelets使用经验总结
JavaEE5学习笔记13：JSF集成Facelets使用经验总结引言JavaServer Faces（JSF）是Java EE的一部分，它是一个用于构建Web应用程序的事件驱动组件模型框架。
Facelets是JSF的一个视图技术，它允许开发者使用XML和XHTML来创建用户界面。
本文将总结JSF集成Facelets的使用经验。
JSF和Facelets简介JSFJSF是一种用于简化Web应用程序开发的方法，它提供了一个组件模型，允许开发者以声明方式构建用户界面。
JSF的核心概念包括组件（UIComponent）、导航（Navigation）、事件和监听器（Event and Listeners）等。
FaceletsFacelets是JSF的一个视图技术，它使用XML和XHTML作为视图的标记语言。
Facelets提供了一种简洁的方式来定义页面模板、重用UI组件和实现页面布局。
JSF集成Facelets的优势组件重用：通过Facelets，可以创建可重用的UI组件，简化开发过程。
模板化：Facelets支持模板化，允许开发者定义页面的公共部分，如页眉和页脚。
声明式导航：JSF的导航规则可以与Facelets结合使用，实现页面间的导航。
事件处理：JSF的事件处理机制可以与Facelets视图无缝集成，处理用户交互。
开始使用JSF和Facelets环境搭建安装Java EE 5 SDK：确保你的开发环境已经安装了Java EE 5 SDK。
配置IDE：在IDE中配置Java EE 5项目，如Eclipse或IntelliJ IDEA。
创建项目新建Java EE Web项目：在IDE中创建一个新的Java EE Web项目。
添加JSF和Facelets库：将JSF和Facelets库添加到项目的类路径中。
配置web.xml配置Faces Servlet：在web.xml文件中配置Faces Servlet，它是处理JSF页面请求的Servlet。
移动应用开发中的常见性能问题及解决方案
移动应用开发中的常见性能问题及解决方案在移动应用开发过程中，性能是一个重要的考量因素。
无论是在iOS还是Android平台上，用户都希望应用能够快速响应并流畅运行。
然而，开发过程中常常会遇到一些性能问题，如应用卡顿、耗电量过高等。
本文将探讨一些常见的性能问题，并提供相应的解决方案。
1. 内存管理问题移动设备的内存相对有限，应用运行过程中若存在内存泄漏或过度使用内存的情况，会导致应用崩溃或响应变慢。
为了解决这个问题，开发人员可以采取以下措施：- 及时释放不再使用的对象和资源。
使用自动释放池或相关的内存管理工具，确保应用中的对象能够在合适的时间被释放。
- 优化图片资源的加载。
使用合适的格式和大小，避免加载过大的图片资源，并在需要时进行图片压缩和缓存。
- 合理使用缓存。
避免频繁地读写本地缓存，可以将一些常用的数据缓存在内存中，以减少IO操作的次数。
2. 网络请求问题移动应用通常需要与后台服务器进行数据交互。
如果网络请求过于频繁或数据传输量过大，会导致应用响应变慢或网络延迟。
以下是解决网络请求问题的一些建议：- 使用异步请求。
将耗时的网络请求放在异步线程中执行，避免阻塞UI线程。
- 合并多个请求。
如果应用需要向服务器发送多个请求，可以将这些请求合并为一个，减少网络延迟和资源消耗。
- 压缩数据。
对于传输的数据，可以使用压缩算法进行压缩，减少数据传输量。
3. 图形渲染问题移动应用中的图形渲染是一个耗费性能的环节。
如果不合理地使用图形渲染API，会导致应用界面卡顿。
以下是一些解决图形渲染问题的方法： - 减少图层混合。
在绘制界面时，尽量减少使用透明度和阴影等效果，以避免过多的图层混合操作。
- 使用硬件加速。
通过使用硬件加速API，如OpenGL ES等，可以将图形渲染过程交给GPU处理，提高渲染性能。
- 图片渲染优化。
合理使用图片资源，并使用合适的压缩格式，如WebP或JPEG XR，以减少加载和渲染时间。
4. 电池寿命问题移动应用运行时，耗电量是用户非常关注的问题。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
这篇文章，是PRO JAVA EE 5 Performance Management and Optimization 的一个章节，作者Steven Haines分享了他在调优企业级JAVA应用时所遇到的常见问题。
Java EE（Java企业开发平台）应用程序，无论应用程序服务器如何部署，所面对的一系列问题大致相同。作为一个JAVAEE问题解决专家，我曾经面对过众多的环境同时也写了不少常见问题的观察报告。在这方面，我觉得我很象一个汽车修理工人：你告诉修理工人发动机有声音，他就会询问你一系列的问题，帮你回忆发动机运行的情形。从这些信息中，他寻找到可能引起问题的原因。
众多解决问题的方法思路基本相同，第一天我同要解决问题的客户接触，接触的时候，我会寻找已经出现的问题以及造成的负面的影响。了解应用程序的体系结构和问题表现出的症状，这些工作很够很大程度上提高我解决问题的几率。在这一节，我分享我在这个领域遇过的常见问题和他们的症状。希望这篇文章能成为你JAVAEE的故障检测手册。
版权声明：任何获得Matrix授权的网站，转载时请务必保留以下作者信息和链接 作者:Steven Haines;tsr106 原文:http://www.javaworld.com/javaworld/jw-06-2006/jw-0619-tuning.html Matrix:http://www.matrix.org.cn/resource/article/44/44575_JAVAEE+Performance+Tuning.html 关键字:VTJAVAEE;Performance Tuning
内存溢出错误 最常见的折磨着企业级应用程序的错误是让人恐惧的outofmemoryError(内存溢出错误) 这个错误引起下面这些典型的症状： ----应用服务器崩溃 ----性能下降 ----一个看起来好像无法结束的死循环在重复不断的执行垃圾收集，它会导致程序停止运行，并且经常导致应用服务器崩溃 不管症状是什么，如果你想让程序恢复正常运行，你一般都需要重新启动应用服务器。
引发out-of-memory 错误的原因 在你打算解决out-of-memory 错误之前，首先了解为什么会引发这个错误对你有很大的帮助。如果JVM里运行的程序, 它的内存堆和持久存储区域的都满了，这个时候程序还想创建对象实例的话，垃圾收集器就会启动，试图释放足够的内存来创建这个对象。这个时候如果垃圾收集器没有能力释放出足够的内存，它就会抛出OutOfMemoryError内存溢出错误。
Out-of-memory错误一般是JAVA内存泄漏引起的。回忆上面所讨论的内容，内存泄漏的原因是一个对象虽然不被使用了，但是依然还有对象引用他。当一个对象不再被使用时，但是依然有一个或多个对象引用这个对象，因此垃圾收集器就不会释放它所占据的内存。这块内存就被占用了，堆中也就少了块可用的空间。在WEB REQUESTS中这种类型的的内存泄漏很典型，一两个内存对象的泄漏可能不会导致程序服务器的崩溃，但是10000或者20000个就可能会导致这个恶果。而且，大多数这些泄漏的对象并不是象DOUBLE或者INTEGER这样的简单对象，而可能是存在于堆中一系列相关的对象。例如，你可能在不经意间引用了一个Person对象，但是这个对象包含一个Profile对象，此对象还包含了许多拥有一系列数据的PerformanceReview对象。这样不只是丢失了那个Person对象所占据的100 bytes的内存，你丢失了这一系列相关对象所占据的内存空间，可能是高达500KB甚至更多。
为了寻找这个问题的真正根源，你需要判断是内存泄漏还是以OutOfMemoryError形式出现的其他一些故障。我使用以下2种方法来判断： ----深入分析内存数据 ----观察堆的增长方式
不同JVM（JAVA虚拟机）的调整程序的运作方式是不相同的，例如SUN和IBM的JVM，但都有相同的的地方。
SUN JVM的内存管理方式 SUN的JVM是类似人类家族，也就是在一个地方创建对象，在它长期占据空间之前给它多次死亡的机会。 SUN JVM会划分为： 1 年轻的一代（Young generation），包括EDEN和2个幸存者空间（出发地和目的地the From space and the To space） 2 老一代(Old generation) 3 永久的一代(Permanent generation)
图1 解释了SUN 堆的家族和空间的详细分类 对象在EDEN出生就是被创建，当EDEN满了的时候，垃圾收集器就把所有在EDEN中的对象扫描一次，把所有有效的对象拷贝到第一个幸存者空间，同时把无效的对象所占用的空间释放。当EDEN再次变满了的时候，就启动移动程序把EDEN中有效的对象拷贝到第二个幸存者空间，同时，也将第一个幸存者空间中的有效对象拷贝到第二个幸存者空间。如果填充到第二个生存者空间中的有效对象被第一个生存者空间或EDEN中的对象引用，那么这些对象就是长期存在的（也就是说，他们被拷贝到老一代）。若垃圾收集器依据这种小幅度的调整收集（minor collection）不能找出足够的空间，就是象这样的拷贝收集（copy collection），就运行大幅度的收集，就是让所有的东西停止（stop-the-world collection）。运行这个大幅度的调整收集时，垃圾收集器就停止所有在堆中运行的线程并执行清除动作（mark-and-sweep collection），把新一代空间释放空并准备重启程序。
图2和图3展示的是了小幅度收集如何运行 图2。对象在EDEN被创建一直到这个空间变满。 图3。处理的顺序十分重要：垃圾收集器首先扫描EDEN和生存者空间，这就保证了占据空间的对象有足够的机会证明自己是有效的。 图4展示了一个小幅度调整是如何运行的 图4：当垃圾收集器释放所有的无效的对象并把有效的对象移动到一个更紧凑整齐的新空间，它将EDEN和生存者空间清空。
以上就是SUN实现的垃圾收集器机制，你可以看出在老一代中的对象会被大幅度调整器收集清除。长生命周期的对象的清除花费的代价很高，因此如果你希望生命周期短的对象在占据空间前及时的死亡，就需要一个主垃圾收集器去回收他们的内存。
上面所讲解的东西是为了更好的帮助我们识别出内存泄漏。当JAVA中的一个对象包含了一个并不想要的一个指向其他对象的引用的时候，内存就会泄漏，这个引用阻止了垃圾收集器去回收它所占据的内存。采用这种机制的SUN 虚拟机，对象不会被丢弃，而是利用自己特有的方法把他们从乐园和幸存者空间移动到老一代地区。因此，在一个基于多用户的WEB环境，如果许多请求造成了泄漏，你就会发现老一代的增长。
图5显示了那些潜在可能造成泄漏的对象：主收集器收集后遗留下来占据空间的对象会越来越多。不是所有的占据空间的对象都造成内存泄漏，但是造成内存泄漏的对象最终都占据者空间。如果内存泄漏的确存在，这些造成泄漏的对象就会不断的占据空间，直至造成内存溢出。
因此，我们需要去跟踪垃圾收集器在处理老一代中的运行：每次垃圾收集器大幅度收集运行时，有多少内存被释放？老一代内容是不是按一定的原理来增长？ 图5。阴影表示在经过大幅度的收集后幸存下来的对象，这些对象是潜在可能引发内存泄漏的对象 一部分这些相关的信息是可以通过跟踪API得到，更详细的信息通过详细的垃圾收集器的日志也可以看到。和所有的跟踪技术一样，日值记录详细的程度影响着JVM的性能，你想得到的信息越详细，付出的代价也就越高。为了能够判断内存是否泄漏，我使用了能够显示辈分之间所有的不同的较权威的技术来显示他们的区别，并以此来得到结果。SUN 的日志报告提供的信息比这个详细的程度超过5％，我的很多客户都一直使用那些设置来保证他们管理和调整垃圾收集器。下面的这个设置能够给你提供足够的分析数据： –verbose:gc –xloggc:gc.log –XX:+PrintGCDetails –XX:+PrintGCTimeStamps
明确发现在整个堆中存在有潜在可能泄漏内存的情况，用老一代增长的速率才比较有说服力。切记调查不能决定些什么：为了能够最终确定你内存泄漏，你需要离线在内存模拟器中运行你的应用程序。
IBM JVM内存管理模式 IBM的JVM的机制有一点不同。它不是运行在一个巨大的继承HEAP中，它仅在一个单一的地区维护了所有的对象同时随着堆的增长来释放内存。这个堆是这样运行的：在一开始运行的时候，它会很小，随着对象实例不断的填充，在需要执行垃圾收集的地方清除掉无效的对象同时把所有有效的对象紧凑的放置到堆的底部。因此你可能猜测到了，如果想寻找可能发生的内存泄漏应该观察堆中所有的动作，堆的使用率是在提高？
如何分析内存泄漏 内存泄漏非常难确定，如果你能够确定是请求导致的，那你的工作就非常简单了。把你的程序放入到运行环境中，并在内存模拟器中运行，按下面的步骤来： 1． 在内存模拟器中运行你的应用程序 2． 执行使用方案（制造请求）以便让程序在内存中装载请求所需要的所有的对象，这可以为以后详细的分析排除不必要的干扰 3． 在执行使用方案前对堆进行拍照以便捕获其中所有运行的对象。 4． 再次运行使用方案。 5． 再次拍照，来捕获使用方案运行之后堆中所有对象的状态。 6． 比较这2个快照，找出执行使用方案后本不应该出现在堆中的对象。
这个时候，你需要去和开发者交流，告诉他你所碰到的棘手的请求，他们可以判断究竟是对象泄漏还是为了某个目的特地让对象保留下来的。如果执行完后并没有发现内存泄漏的情况，我一般会转到步骤4再进行多次类似的跟踪。比如，我可能会将我的请求反复运行17次，希望我的泄漏分析能够得到17个情况（或更多）。这个方法不一定总有用，但如果是因为请求引起的对象泄漏的话，就会有很大的帮助。
如果你无法明确的判断泄漏是因为请求引发的，你有2个选择： 1． 模拟每一个被怀疑的请求直至发现内存泄漏 2． 存配置一个内存性能跟踪工具
第一个选项在小应用程序中是确实可用的或者你非常走运的解决了问题，但对大型应用程序不太有用。如果你有跟踪工具的话第二个选择是比较有用的。这些工具利用字节流工具跟踪对象的创建和销毁的数量，他们可以报告特定类中的对象的数量状态，例如把Collections类作为特定的请求。例如，一个跟踪工具可以跟踪/action/login.do请求，并在它完成后将其中的100个对象放入HASHMAP中。这个报告并不能告诉你造成泄漏的是代码还是某个对象，而是告诉你在内存模拟器中应该留意那些类型的请求。把程序服务器放到产品环境中并不会使他们变敏感，而是跟踪性能的工具可以使你的工作变的更简单化。