Surviving Generations and Memory Leaks
2015-12-18 15:36
387 查看
摘自java performance
Surviving Generations and Memory Leaks
To understand the Generations column in the memory profiling results view, you have to
think about the JVM’s Garbage Collection process. Every time the garbage collector runs
each object either survives and continues to occupy heap memory, or it is removed and its
memory is freed. If an object survives, then its age has increased by a value of 1. In other
words, the age of an object is simply the number of garbage collections that it has survived.
The value of Generations is the number of different object ages.
For example, assume several objects were all allocated when your application first started.
Further, another group of objects was allocated at the midpoint of your application’s run.
And finally, some objects have just been allocated and have only survived one garbage
collection. If the garbage collector has run 80 times, then all the objects in the first group
will have an age of 80, all the objects in the second group will have an age of 40, and
all of the objects in the third group will have an age of 1. In this example, the value of
Generations is 3, because there are three different ages among all the objects on the
heap: 80, 40, and 1.
In most Java applications the value for Generations eventually stabilizes. This is because the
application has reached a point where all long-lived objects have been allocated. Objects
that are intended to have a shorter life span do not impact the Generations count because
they will eventually be garbage collected.
If the Generations value for your application continues to increase as the application
runs, it could be an indication of a memory leak. In other words, your application is
continuing to allocate objects over time, each of which has a different age because it has
survived a different number of garbage collections. If the objects were being properly
garbage collected, the number of different object ages would not be increasing.
Surviving Generations and Memory Leaks
To understand the Generations column in the memory profiling results view, you have to
think about the JVM’s Garbage Collection process. Every time the garbage collector runs
each object either survives and continues to occupy heap memory, or it is removed and its
memory is freed. If an object survives, then its age has increased by a value of 1. In other
words, the age of an object is simply the number of garbage collections that it has survived.
The value of Generations is the number of different object ages.
For example, assume several objects were all allocated when your application first started.
Further, another group of objects was allocated at the midpoint of your application’s run.
And finally, some objects have just been allocated and have only survived one garbage
collection. If the garbage collector has run 80 times, then all the objects in the first group
will have an age of 80, all the objects in the second group will have an age of 40, and
all of the objects in the third group will have an age of 1. In this example, the value of
Generations is 3, because there are three different ages among all the objects on the
heap: 80, 40, and 1.
In most Java applications the value for Generations eventually stabilizes. This is because the
application has reached a point where all long-lived objects have been allocated. Objects
that are intended to have a shorter life span do not impact the Generations count because
they will eventually be garbage collected.
If the Generations value for your application continues to increase as the application
runs, it could be an indication of a memory leak. In other words, your application is
continuing to allocate objects over time, each of which has a different age because it has
survived a different number of garbage collections. If the objects were being properly
garbage collected, the number of different object ages would not be increasing.
相关文章推荐
- 实现统计每个栏目下的文章总数的调用
- jQuery中trigger()与bind()用法分析
- 关于ThinkPHP中$this->redirect的疑问。
- Android onMeasure and onLayout
- 笔记三:Centos 7 64bit 下JDK的安装与配置
- Android使用Fragment来实现TabHost的功能(解决切换Fragment状态不保存)以及各个Fragment之间的通信
- FileItem类
- android bitmap compress(图片压缩)
- 剑指offer系列之五十七:二叉树的下一个节点
- 关于SearchView的一些小细节
- oauth2.0认证和授权原理
- Git简易入门教程
- 如何使用 Idea 远程调试 Java 代码
- 移动webapp页面适配方案
- spring mvc+shiro +cas +spring-session 的通用权限管理系统
- LNK1123: 转换到 COFF 期间失败: 文件无效或损坏
- 程序集重新定向与指定加载程序集时公共语言运行时搜索的子目录。
- iOS中写一个完整的单例
- 路线
- Eclipse快捷键