1、JVM的内存模型
从大的方面来讲，JVM的内存模型分为两大块：永久性内存（Permanent space）和堆内存（heap space）。栈内存（stack space）一般不归在JVM内存模型中，栈内存属于线程级别。每个线程都有独立的栈内存空间。
?Young Gen：年轻代，包括1个Eden区和2个Survivor区，新创建的对象（大部分为短周期的对象）将进入这个区，虚拟机会频繁地对这个区进行垃圾回收。
?Old Gen：年老代，当对象在Young Gen呆地足够久（经过几次的垃圾回收仍然存在）或Young Gen空间不足时，对象将进入Old Gen，由于一般是生命周期比较长的对象，因此虚拟机对这块内存的回收频度会比较低，一旦回收，使用的将是一个耗时的Full GC，另外，一旦堆空间不足时，虚拟机也会尝试去回收这个区。
?Perm Gen：持久代，一些常量定义和类、方法声明及其bytecode都会放在这个区。
1.1 Permanent space
Permanent space是指内存的永久保存区域，主要用于存放加载的class类级对象如class 本身、method、field等。它和存放类实例的Heap区域不同，GC（Garbage Coolection）不
会在主程序运行期对Permanent space进行清理。如果应用中有很有class的话，且permanent space设置得比较小就有可能会出现这样的错误。
Permanent space大小的设置：
-XX：PermSize用于设置永久保存区域初始大小；-XX：MaxPermSize用于设置永久保存区域的最大值。
1.2 Heap space
Heap space由Old Generation和New Generation组成，Old Generation存放生命周期长久的实例对象，而新的对象实例一般放在New Generation。New Generation可再分为Eden区、Survivor区，新对象实例总是首先放在Eden区，Survivor作为Eden区和Old区的缓冲，可以向Old区转移活动的对象实例。
其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1 /4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms 设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。
注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。
垃圾回收分多级，0级为全部(Full)的垃圾回收，会回收OLD段中的垃圾；1级或以上为部分垃圾回收，只会回收New中的垃圾，内存溢出通常发生于OLD段或Perm段垃圾回收后，仍然无内存空间容纳新的Java对象的情况。
当一个URL被访问时，内存申请过程如下：
A. JVM会试图为相关Java对象在Eden区中初始化一块内存区域
B. 当Eden空间足够时，内存申请结束。否则到下一步
C. JVM试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）, 释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区
D. Survivor区被用来作为Eden及OLD的中间交换区域，当OLD区空间足够时，Survivor 区的对象会被移到Old区，否则会被保留在Survivor区
E. 当OLD区空间不够时，JVM会在OLD区进行完全的垃圾收集（0级）
F. 完全垃圾收集后，若Survivor及OLD区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现"out of memory错误"、
2、内存分配的相关参数
ms/mx：定义NEW+OLD段的总尺寸，ms为JVM启动时NEW+OLD的内存大小；mx 为最大可占用的NEW+OLD内存大小。在用户生产环境上一般将这两个值设为相同，以减
少运行期间系统在内存申请上所花的开销。
NewSize/MaxNewSize：定义NEW段的尺寸，NewSize为JVM启动时NEW的内存大小；MaxNewSize为最大可占用的NEW内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
PermSize/MaxPermSize：定义Perm段的尺寸，PermSize为JVM启动时Perm的内存大小；MaxPermSize为最大可占用的Perm内存大小。在用户生产环境上一般将这两个值设为相同，以减少运行期间系统在内存申请上所花的开销。
SurvivorRatio：设置Survivor空间和Eden空间的比例。
NewRatio：设置Old区域与NEW区域的比例。
3、GC的算法
1）标记非活动对象
－－何为非活动对象，通俗的讲，就是无引用的对象。
追踪root对象算法：深度追踪root对象，将heap中所有被引用到的root做标志，所有未被标志的对象视为非活动对象，所占用的空间视为非活动内存。
2）清理非活动对象
Copy算法：
方法：将内存分为两个区域（from space和to space）。所有的对象分配内存都分配到from space。在清理非活动对象阶段，把所有标志为活动的对象，copy到to space，之后清楚from space空间。然后互换from sapce和to space的身份。既原先的from space变成to sapce，原先的to space变成from space。每次清理，重复上述过程。
优点：copy算法不理会非活动对象，copy数量仅仅取决为活动对象的数量。并且在copy 的同时，整理了heap空间，即，to space的空间使用始终是连续的，内存使用效率得到提高。缺点：划分from space和to space，内存的使用率是1／2。
Compaction算法：
方法：在清理非活动对象阶段，删除非活动对象占用内存，并且把活动对象向heap的底部移动，直到所有的活动对象被移到heap的一侧。
优点：无须划分from sapce和to space，提高内存的使用率。并且compaction后的内存空间也是连续分配的。
缺点：该算法相对比较复杂。
如果能对这两种对象区分对象，那么会提高GC的效率。在sun jdk gc中（具体的说，是在jdk1.4之后的版本），提出了不同生命周期的GC策略。
young generation：
生命周期很短的对象，归为young generation。由于生命周期很短，这部分对象在gc的时候，
很大部分的对象已经成为非活动对象。因此针对young generation的对象，采用copy算法，只需要将少量的存活下来的对象copy到to space。存活的对象数量越少，那么copy算法的效率越高。
young generation的gc称为minor gc。经过数次minor gc，依旧存活的对象，将被移出young generation，移到tenured generation（下面将会介绍）
young generation分为：
eden：每当对象创建的时候，总是被分配在这个区域
survivor1：copy算法中的from space
survivor2：copy算法中的to sapce （备注：其中survivor1和survivor2的身份在每次minor gc后被互换）minor gc的时候，会把eden+survivor1(2)的对象copy到survivor2(1)去。
tenured generation：生命周期较常的对象，归入到tenured generation。一般是经过多次minor gc，还依旧存活的对象，将移入到tenured generation。（当然，在minor gc中如果存活的对象的超过survivor的容量，放不下的对象会直接移入到tenured generation）。tenured generation的gc称为major gc，就是通常说的full gc。采用compactiion算法。由于tenured generaion区域比较大，而且通常对象生命周期都比较常，compaction需要一定时间。所以这部分的gc时间比较长。
minor gc可能引发full gc。当eden＋from space的空间大于tenured generation区的剩余空间时，会引发full gc。这是悲观算法，要确保eden＋from space的对象如果都存活，必须有足够的tenured generation空间存放这些对象。
Permanet Generation：
该区域比较稳定，主要用于存放classloader信息，比如类信息和method信息。对于spring hibernate这些需要动态类型支持的框架，这个区域需要足够的空间。这部分内容相对比较理论，可以结合jstat，jmap等命令（当然也可以使用jconsole，jprofile，gciewer等工具），观察jdk gc的情况。
4、jdk自带的jps jmap jstat 等工具jps:相当于linux下的ps,列出所有java相关线程的pid等信息
example:
$ jps
18861 Bootstrap
1418 Jps
jmap:
显示java进程内存使用的相关信息
jmap pid 打印内存使用的摘要信息
jmap -histopid >mem.txt 打印比较简单的各个有多少个对象占了多少内存的信息，一般重定向的文件
jmap -dump:format=b,file= mem.dat pid 将内存使用的详细情况输出到em.dat 文件
jmap -dump:live,format=b,file=heap.bin
analyze heap
将二进制的heap dump文件解析成human-readable的信息，自然是需要专业工具的帮助，这里推荐Memory Analyzer 。
用jhat命令可以参看 jhat -port 7000 mem.dat
在浏览器中访问：http://10.5.22.65:7000/ 查看详细信息
jstat:
显示java虚拟机的一些统计信息
jstat -选项 pid 间隔显示时间显示次数
jstat -gc 18861 250 10
jstat -gccapacity 18861 250 10
jstat -gcnew 18861 250 10
jstat -gcnewcapacity 18861 250 10
jstat -gcold 18861 250 10
jstat -gcutil pid 1000 200
表示每1秒打印一次，共200次
S0 — Heap上的 Survivor space 0 区已使用空间的百分比
S1 — Heap上的 Survivor space 1 区已使用空间的百分比
E — Heap上的 Eden space 区已使用空间的百分比
— Heap上的 Old space 区已使用空间的百分比
P — Perm space 区已使用空间的百分比
YGC —从应用程序启动到采样时发生 Young GC 的次数
YGCT–从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC —从应用程序启动到采样时发生 Full GC 的次数
FGCT–从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT —从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
调试流程
内存泄漏一般都是有一定特征的，任何代码和数据都要占用内存，简单总结内存泄漏的特征是内存占用不可控制，GC不可回收。追踪内存使用量的曲线发现一些特征，在估计虚拟机即将崩溃时，使用 jmap -histopid >mem.txt 发现相关内存泄漏的对象占用非常打比例的内存空间，然后很容易猜测问题大概的位置，一下子就解决了。
对于内存泄露的压力测试也开始实实在在的做起来。经过这次问题的定位和解决以后，大致觉得对于一个大用户量应用要放心的话，那么需要做这么几步。
1.在GC输出的环境下，大压力下做多天的测试。（可以在 JAVA_OPTS增加
-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError）
2.检查GC输出日志来判断是否有内存泄露。（这部分后面有详细的实例说明）
3.如果出现内存泄露问题，则使用jprofiler等工具来排查内存泄露点（之所以不一开始使用，因为jprofiler等工具对于压力测试有影响，使得大压力无法上去，也使问题不那么容易暴露）
4.解决问题，并在重复2步骤。
（这里的内存泄露问题就是在以前blog写过的jdk的concurrent包内LinkedBlockingQueue的poll方法存在比较严重的内存泄露，调用频率越高，内存泄露的越厉害）
两次压力测试都差不多都是两天，测试方案如下：
开始50个并发，每个并发每次请求完毕后休息0.1秒，10分钟后增长50
个并发，按此规律增长到500并发。
先说一下日志输出的结构：(1.6和1.5略微有一些不同，只是1.6对于时间统计更加细致)
[GC [
Jdk1.5 log：
启动时GC输出：
[GC [DefNew: 209792K->4417K(235968K), 0.0201630 secs]
246722K->41347K(498112K), 0.0204050 secs]
[GC [DefNew: 214209K->4381K(235968K), 0.0139200 secs]
251139K->41312K(498112K), 0.0141190 secs]
一句输出：
新生代回收前209792K，回收后4417K，回收数量205375K，Heap总量回收前246722K回收后41347K，回收总量205375K。这就表示100%的收回，没有任何新生代的对象被提升到中生代或者永久区（名字说的不一定准确，只是表达意思）。
第二句输出：
按照分析也就只是有1K内容被提升到中生代。
运行一段时间后：
[GC [DefNew: 210686K->979K(235968K), 0.0257140 secs]
278070K->68379K(498244K), 0.0261820 secs]
[GC [DefNew: 210771K->1129K(235968K), 0.0275160 secs]
278171K->68544K(498244K), 0.0280050 secs]
第一句输出：
新生代回收前210686K，回收后979K，回收数量209707K，Heap总量回收前278070K回收后68379K，回收总量209691K。这就表示有16k没有被回收。
第二句输出：
新生代回收前210771K，回收后1129K，回收数量209642K，Heap总量回收前278171K回收后68544K，回收总量209627K。这就表示有15k没有被回收。比较一下启动时与现在的新生代占用内存情况和Heap使用情况发现Heap的使用增长很明显，新生代没有增长，而Heap使用总量增长了27M，这就表明可能存在
内存泄露，虽然每一次泄露的字节数很少，但是频率很高，大部分泄露的对象都被升级到了中生代或者持久代。
又一段时间后：
[GC [DefNew: 211554K->1913K(235968K), 0.0461130 secs]
350102K->140481K(648160K), 0.0469790 secs]
[GC [DefNew: 211707K->2327K(235968K), 0.0546170 secs]
350275K->140921K(648160K), 0.0555070 secs]
第一句输出：
新生代回收前211554K，回收后1913K，回收数量209641K，Heap总量回收前350102K回收后140481K，回收总量209621K。这就表示有20k没有被回收。分析到这里就可以看出每一次泄露的内存只有10几K，但是在大压力长时间的测试下，内存泄露还是很明显的，此时Heap已经增长到了140M，较启动时已经增长了100M。同时GC占用的时间越来越长。
后续的现象：
后续观察日志会发现，Full GC的频率越来越高，收集所花费时间也是越来越长。（Full GC定期会执行，同时局部回收不能满足分配需求的情况下也会执行）。
[Full GC [Tenured: 786431K->786431K(786432K), 3.4882390 secs] 1022399K->1022399K(1022400K), [Perm : 36711K->36711K(98304K)],
3.4887920 secs]
https://www.doczj.com/doc/ad15881794.html,ng.OutOfMemoryError: Java heap space
Dumping heap to java_pid7720.hprof ...
出现这个语句表示内存真的被消耗完了。
Jdk1.6 log：
启动时GC的输出：
[GC [PSYoungGen: 221697K->31960K(229376K)] 225788K->36051K(491520K), 0.0521830 secs] [Times: user=0.26 sys=0.05, real=0.05 secs]
[GC [PSYoungGen: 228568K->32752K(229376K)] 232659K->37036K(491520K), 0.0408620 secs] [Times: user=0.21 sys=0.02, real=0.04 secs]
第一句输出：
新生代回收前221697K，回收后31960K，回收数量189737K，Heap总量回收前225788K回收后36051K，回收总量189737K。100%被回收。
运行一段时间后输出：
[GC [PSYoungGen: 258944K->2536K(259328K)] 853863K->598135K(997888K), 0.0471620 secs] [Times: user=0.15 sys=0.00, real=0.05 secs]
[GC [PSYoungGen: 259048K->2624K(259328K)] 854647K->598907K(997888K), 0.0462980 secs] [Times: user=0.16 sys=0.02, real=0.04 secs]
第一句输出：
新生代回收前258944K，回收后2536K，回收数量256408K，Heap总量回收前853863K回收后598135K，回收总量255728K。680K没有被回收，但这并不意味着就会产生内存泄露。同时可以看出GC回收时间并没有增加。
在运行一段时间后输出：
[GC [PSYoungGen: 258904K->2488K(259264K)] 969663K->713923K(1045696K), 0.0485140 secs] [Times: user=0.16 sys=0.01, real=0.04 secs]
[GC [PSYoungGen: 258872K->2448K(259328K)] 970307K->714563K(1045760K), 0.0473770 secs] [Times: user=0.16 sys=0.01, real=0.05 secs]
第一句输出：
新生代回收前258904K，回收后2488K，回收数量256416K，Heap总量回收前969663K回收后713923K，回收总量255740K。676K没有被回收，同时总的Heap 也有所增加。
此时看起来好像和1.5的状况一样。但是查看了一下Full GC的执行还是400-500次GC执行一次，因此继续观察。
运行一天多以后输出：
[GC [PSYoungGen: 257016K->3304K(257984K)] 1019358K->766310K(1044416K), 0.0567120 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]
[GC [PSYoungGen: 257128K->2920K(258112K)] 1020134K->766622K(1044544K), 0.0549570 secs] [Times: user=0.19 sys=0.00, real=0.05 secs]
可以发现Heap增长趋缓。
运行两天以后输出：
[GC [PSYoungGen: 256936K->3584K(257792K)] 859561K->606969K(1044224K), 0.0565910 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]
[GC [PSYoungGen: 256960K->3368K(257728K)] 860345K->607445K(1044160K), 0.0553780 secs] [Times: user=0.18 sys=0.01, real=0.06 secs]
发现Heap反而减少了，此时可以对内存泄露问题作初步排除了。（其实在jdk1.6环境下用jprofiler来观察，对于concurrent那个内存泄露点的跟踪发现，内存的确还是会不断增长的，不过在一段时间后还是有回收，因此也就可以部分解释前面出现的情况）
总结：
对于GC输出的观察需要分两个维度来看。一个是纵向比较，也就是一次回收对于内存变化的观察。一个是横向比较，对于长时间内存分配占用情况的比较，这部分比较需要较长时间的观察，不能仅仅凭短时间的几个抽样比较，因为对于抽样来说，Full GC前后的区别，运行时长的区别，资源瞬时占用的区别都会影响判断。同时要结合Full GC发生的时间周期，每一次GC收集所耗费的时间作为辅助判断标准。
顺便说一下，Heap的 YoungGen,OldGen,PermGen的设置也是需要注意的，并不是越大越好，越大执行收集的时间越久，但是可能执行Full GC的频率会比较低，因此需要权衡。这些仔细的去了解一下GC的基础设计思想会更有帮助，不过一般用默认的也不错。还有就是可以配置一些特殊的GC，并行，同步等等，充分利用多CPU的资源。
对于GC的优化可以通过现在很多图形工具来做，也可以类似于我这样采用最原始的分析方式，好处就是任何时间任何地点只要知道原理就可以分析无需借助外部工具。
5、针对现网出现内存溢出的说明
项目进行SSB改造以后，当客户端从服务器抓起大笔数据的时候，服务器报一个二进制流的错误，这个错误其实是一个内存溢出的错误。 提纲 故障现象 故障分析与解决 Code Review 工具与方法 故障现象 用户反映在进行数据导出时经常出现下面的错误:输入流是无效的二进制格式。开始内容(以字节为单位)是: 53-79-73-74-65-6D-2E-4F-75-74-4F-66-4D-65-6D-6F-72... 坏┏鱿指么砦蠛?/SPAN>,其他后面导出的用户都会出现该错误,导致无法进行操作。 故障分析 System.OutOfMemoryException 发生 53-79-73-74-65-6D-2E-4F-75-74-4F-66-4D-65-6D-6F-72... System.OutOfMemor ... System.OutOfMemoryException 发生的两种情况 应用程序消耗了过多的内存 内存碎片过多 内存Dump分析
有446M的free内存, 但最大的free内存块只有26M 不足64M 。内存碎片问题。 -------------------- Type SUMMARY -------------------------- TotSize ( KB) Pct(Tots) Usage 1b450000 ( 446784) : 21.30% :
1 在C语言代码(文本文件)形成可执行程序(二进制文件)，需要经过 预处理---编译—汇编—链接。 编译过程是把C语言文本文件生成汇编程序， 汇编过程是把汇编程序形成二进制机器代码， 链接则是将各个源文件生成的二进制代码文件组合成一个文件。 2 C语言的程序经过编译--------链接后，将形成一个统一文件，它由几个部分组成。在程序运行时又会产生其他几个部分，各个部分代表了不同的存储区域。 3 说明：C语言程序分为映像和运行时两种状态。在编译-----链接后形成映像中，将只包含代码段(Text)、只读数据段(RO Data)和读写数据段(RW Data)。在程序运行之前，将动态生成未初始化数据段BSS。在程序的运行时还将动态生成堆Heap区域和栈Stack区域。 C语言在编译链接后，将生成代码段(Text)、只读数据段(RO Data)和读写数据段(RW Data)。在运行时，除了上述三个区域外，还包括未初始化数据段BSS区域和栈Stack区域。 代码段(Text) 只读数据段(RO Data) -----const定义的变量常量 Static修饰符的变量不管在函数内部或外部全在静态区 全局变量----静态区 读写数据段(RW Data) ---已初始化的全局变量 未初始化数据段BSS ---直接定义的全局变量 堆Heap区域----malloc 栈Stack区域----主要存储以下三种：函数内部的动态变量函数参数函数返回值
int main() char *p=”tiger”,系统在栈上开辟了四个字节存储p的数值。, tiger”在只读存储区，因此tiger”的内容不能改变，*p= tiger”，char *p = “tiger” ; 表示地址赋值。因此，p指向了只读存储区，因此改变p指向p[1+=’l’; 的内容会引起段错误。但是因为P在存放在栈上，因此p的数p++ ; 值是可以改变的，因此p++是正确的。 p rintf(“%s\n”,p); } typedef char *pStr ; ----经过编译提示错误为：error:increment of read-only variable ‘p2’ int main() 1>const使用的基本形式为const char m ; 限定m不可变 { 2>替换const char *pm ; 限定*pm不可变,pm是可变的，因此c har string*6+ = “tiger” ;p1++是对的。 const char *p1 = string ; 3>替换const newType m;限定m不可变,所以p2是不可变的。const pStr p2 = string ; p2++是错误的。 p1 ++ ; const (char *) pContent;//pContent是const，*pContent是可变 p2 ++ ; p rintf(“p1=%s\np2=%s\n”,p1,p2); }
1.怎么保证多人开发进行内存泄露的检查. 1>使用Analyze进行代码的静态分析 2>为避免不必要的麻烦, 多人开发时尽量使用ARC 2．非自动内存管理情况下怎么做单例模式. 创建单例设计模式的基本步骤· >声明一个单件对象的静态实例,并初始化为nil。 >创建一个类的类工厂方法,当且仅当这个类的实例为nil时生成一个该类的实例>实现NScopying协议, 覆盖allocWithZone:方法,确保用户在直接分配和初始化对象时,不会产生另一个对象。 >覆盖release、autorelease、retain、retainCount方法, 以此确保单例的状态。>在多线程的环境中,注意使用@synchronized关键字或GCD,确保静态实例被正确的创建和初始化。 3．对于类方法（静态方法）默认是autorelease的。所有类方法都会这样吗？ 1> 系统自带的绝大数类方法返回的对象,都是经过autorelease的 4．block在ARC中和MRC中的用法有什么区别,需要注意什么 1.对于没有引用外部变量的Block，无论在ARC还是非ARC下，类型都是__NSGlobalBlock__，这种类型的block可以理解成一种全局的block，不需要考虑作用域问题。同时，对他进行Copy或者Retain操作也是无效的 2.应注意避免循环引用 5．什么情况下会发生内存泄漏和内存溢出？ 当程序在申请内存后，无法释放已申请的内存空间(例如一个对象或者变量使用完成后没有释放,这个对象一直占用着内存)，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。内存泄露会最终会导致内存溢出！ 当程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个int,但给它存了long才能存下的数，那就是内存溢出。 6．[NSArray arrayWithobject:
为了保证所保存的数据不丢失，DRAM必须定时进行刷新，DDR3也不例外。 为了最大的节省电力，DDR3采用了一种新型的自动自刷新设计（ASR，Automatic Self-Refresh）。当开始ASR之后，将通过一个内置于DRAM芯片的温度传感器来控制刷新的频率，因为刷新频率高的话，消电就大，温度也随之升高。而温度传感器则在保证数据不丢失的情况下，尽量减少刷新频率，降低工作温度。不过DDR3的ASR是可选设计，并不见得市场上的DDR3内存都支持这一功能，因此还有一个附加的功能就是自刷新温度范围（SRT，Self-Refresh Temperature）。通过模式寄存器，可以选择两个温度范围，一个是普通的的温度范围（例如0℃至85℃），另一个是扩展温度范围，比如最高到95℃。对于DRAM内部设定的这两种温度范围，DRAM将以恒定的频率和电流进行刷新操作。 局部自刷新（RASR，Partial Array Self-Refresh）这是DDR3的一个可选项，通过这一功能，DDR3内存芯片可以只刷新部分逻辑Bank，而不是全部刷新，从而最大限度的减少因自刷新产生的电力消耗。这一点与移动型内存（Mobile DRAM）的设计很相似 FBD、XDR、XDR2内存概述 来自(https://www.doczj.com/doc/ad15881794.html,/) 2009-07-14 1．FBD内存 FBD即Fully-buffer DIMM（全缓存模组技术），它是一种串行传输技术，可以提升内存的容量和传输带宽.是Intel在DDR2、DDR3的基础上发展出来的一种新型内存模组与互联架构，既可以搭配现在的DDR2内存芯片，也可以搭配未来的DDR3内存芯片。FB-DIMM可以极大地提升系统内存带宽并且极大地增加内存最大容量。 FB-DIMM与XDR相比较，虽然性能不及全新架构的XDR，但成本却比XDR要低廉得多。与现有的普通DDR2内存相比，FB-DIMM技术具有极大的优势:在内存频率相同的情况下目前能提供四倍于普通内存的带宽，并且能支持的最大内存容量也达到了普通内存的24倍，系统最大能支持192GB内存。FB-DIMM最大的特点就是采用已有的DDR2内存芯片(以后还将采用DDR3内存芯片)，但它借助内存PCB上的一个缓冲芯片AMB(Advanced Memory Buffer，高级内存缓冲)将并行数据转换为串行数据流，并经由类似PCI Express 的点对点高速串行总线将数据传输给处理器。 与普通的DIMM模块技术相比，FB-DIMM与内存控制器之间的数据与命令传输不再是传统设计的并行线路，而采用了类似于PCI-Express的串行接口多路并联的设计，以串行的方式进行数据传输。在这种新型架构中，每个DIMM上的缓冲区是互相串联的，之间是点对点的连接方式，数据会在经过第一个缓冲区后传向下一个缓冲区，这样，第一个缓冲区和内存控制器之间的连接阻抗就能始终保持稳定，从而有助于容量与频率的提升。 2．XDR内存 XDR就是“eXtreme Data Rate”的缩写，这是Rambus的黄石的最终名称。XDR将Rambus之前公布了一系列新技术集中到了一起，新技术不仅带来了新的内存控制器设计和DRAM模块设计，同时可以工作在相当高的频率，带来让人难以置信的带宽。 XDR内存比较有意思，这次架构同目前实际使用的DDR、DDR II并没有太大的差别，但XDR却依旧拥有自己的知识产权。XDR在今年年内会有样品出现，明年中后期正式推广，同原来一样三星依旧是RAMBUS
登入用友T3软件提示错误；“内存溢出” 登入用友T3软件提示错误；“内存溢出” 系统缺少ufrtprn.ocx组件造成的。首先把c:\windows\system32\ufcomsql\ufrtprn.ocx 这个文件复制到其他地方，再用正常的文件（下面的附件）替换一下，然后重新注册，注册如下：如果操作系统是XP或2003，则：开始–运行 –regsvr32c:\windows\system32\ufcomsql\ufrtprn.ocx；如果操作系统是WINDOWS2000，则：开始–运行–regsvr32c:\winnt\system32\ufcomsql\ufrtprn.ocx。如果还是不行，那么就建议重新安装软件了。 服务异常了，可能是多种原因造成的，你可以在C:\Windows\System32\UF2000.log，打开UF2000.log查看错误详情再处理，如果你不太熟悉软件或者数据库的话，建议把用友安装目录下的ADMIN全部拷贝出来，然后重新安装软件，然后进行数据库附加即可 试一下： 1：执行系统管理，做初始化操作 2：若方法1未执行初始化，可能是这前做过初始化，开始-运行-regedit确定、找到注册表项：[HKEY_LOCAL_MACHINE\SOFTWARE\UFSoft\UF2000\2.0\Setup]，右击删除Setup、再登录系统管理做初始化操作 方法3：若初始化操作建立系统数据库操作失败，可手工建立此系统数据库，还原用友通安装目录\Admin\ Ufsystem.bak文件，还原时数据库名称定义为UFSystem 重启”F8”,回车,进入安全模式，“高级启动选项”，找到“最后一次正确配置”
1.标准链接库提供四个函数实现动态内存管理： （1）分配新的内存区域： void * malloc(size_t size); void *calloc(size_t count , size_t size); （2）调整以前分配的内存区域： void *realloc(void *ptr , size_t size); （3）释放以前分配的内存区域： void free(void *ptr); 2.void * malloc(size_t size); 该函数分配连续的内存空间，空间大小不小于size 个字节。但分配的空间中的内容是未知的。该函数空间分配失败则返回NULL。 3.void *calloc(size_t count , size_t size); 该函数也可以分配连续的内存空间，分配不少于count*size个字节的内存空间。即可以为一个数组分配空间，该数组有count个元素，每个元素占size个字节。而且该函数会将分配来的内存空间中的内容全部初始化为0 。该函数空间分配失败则返回NULL。 4. 以上两个分配内存空间的函数都返回void * （空类型指针或无类型指针）返回的指针值是“分配的内存区域中”第一个字节的地址。当存取分配的内存位置时，你所使用的指针类型决定如何翻译该位置的数据。以上两种分配内存空间的方法相比较，calloc()函数的效果更好。原因是它将分配得来的内存空间按位全部置0 。 5. 若使用上述两种分配内存的函数分配一个空间大小为0 的内存，函数会返回一个空指针或返回一个没有定义的不寻常指针。因此绝不可以使用“指向0 字节区域”的指针。 6. void *realloc(void *ptr , size_t size); 该函数释放ptr所指向的内存区域，并分配一个大小为size字节的内存区域，并返回该区域的地址。新的内存区域可以和旧的内存区域一样，开始于相同的地址。且此函数也会保留原始内存内容。如果新的内存区域没有从原始区域的地址开始，那么此函数会将原始的内容复制到新的内存区域。如果新的内存区域比较大，那么多出来部分的值是没有意义的。 7. 可以把空指针传给realloc()函数，这样的话此函数类似于malloc()函数，并得到一块内存空间。如果内存空间不足以满足内存区域分配的请求，那么realloc()函数返回一个空指针，这种情况下，不会释放原始的内存区域，也不会改变它的内容。 8. void free(void *ptr); 该函数释放动态分配的内存区域，开始地址是ptr，ptr的值可以是空指针。若在调用此函数时传入空指针，则此函数不起任何作用。 9. 传入free() 和realloc()函数的指针（若不为空指针时）必须是“尚未被释放的动态分配内存区域的起始地址”。否则函数的行为未定义。Realloc()函数也可以释放内存空间，例如：Char *Ptr = (char *)malloc(20); 如只需要10个字节的内存空间，且保留前十个字节的内容，则可以使用realloc()函数。 Ptr = Realloc(ptr,10); // 后十个字节的内存空间便被释放
JAVA内存溢出 解决方案 1. 内存溢出类型 1.1. https://www.doczj.com/doc/ad15881794.html,ng.OutOfMemoryError: PermGen space JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。 PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGen space中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行pre compile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。 一个最佳的配置例子：(经过本人验证，自从用此配置之后，再未出现过tomcat死掉的情况) set JAVA_OPTS=-Xms800m -Xmx800m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m 1.2. https://www.doczj.com/doc/ad15881794.html,ng.OutOfMemoryError: Java heap space 第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。
本文详细介绍了虚拟内存的设置和相关问题的解决方法。 内存在计算机中的作用很大，电脑中所有运行的程序都需要经过内存来执行，如果执行的程序很大或很多，就会导致内存消耗殆尽。为了解决这个问题，Windows中运用了虚拟内存技术，即拿出一部分硬盘空间来充当内存使用，当内存占用完时，电脑就会自动调用硬盘来充当内存，以缓解内存的紧张。举一个例子来说，如果电脑只有128MB 物理内存的话，当读取一个容量为200MB的文件时，就必须要用到比较大的虚拟内存，文件被内存读取之后就会先储存到虚拟内存，等待内存把文件全部储存到虚拟内存之后，跟着就会把虚拟内里储存的文件释放到原来的安装目录里了。 当系统运行时，先要将所需的指令和数据从外部存储器(如硬盘、软盘、光盘等)调入内存中，CPU再从内存中读取指令或数据进行运算，并将运算结果存入内存中，内存所起的作用就像一个“二传手”的作用。当运行一个程序需要大量数据、占用大量内存时，内存这个仓库就会被“塞满”，而在这个“仓库”中总有一部分暂时不用的数据占据着有限的空间，所以要将这部分“惰性”的数据“请”出去，以腾出地方给“活性”数据使用。这时就需要新建另一个后备“仓库”去存放“惰性”数据。由于硬盘的空间很大，所以微软Windows操作系统就将后备“仓库”的地址选在硬盘上，这个后备“仓库”就是虚拟内存。在默认情况下，虚拟内存是以名为Pagefile.sys的交换文件
保存在硬盘的系统分区中。 手动设置虚拟内存 在默认状态下，是让系统管理虚拟内存的，但是系统默认设置的管理方式通常比较保守，在自动调节时会造成页面文件不连续，而降低读写效率，工作效率就显得不高，于是经常会出现“内存不足”这样的提示，下面就让我们自已动手来设置它吧。 ①用右键点击桌面上的“我的电脑”图标，在出现的右键菜单中选择“属性”选项打开“系统属性”窗口。在窗口中点击“高级”选项卡，出现高级设置的对话框. ②点击“性能”区域的“设置”按钮，在出现的“性能选项”窗口中选择“高级”选项卡，打开其对话框。 ③在该对话框中可看到关于虚拟内存的区域，点击“更改”按钮进入“虚拟内存”的设置窗口。选择一个有较大空闲容量的分区，勾选“自定义大小”前的复选框，将具体数值填入“初始大小”、“最大值”栏中，而后依次点击“设置→确定”按钮即可，最后重新启动计算机使虚拟内存设置生效。
彻底解决Weblogic报出https://www.doczj.com/doc/ad15881794.html,ng.OutOfMemoryError: PermGen space问题： 打开域下面的bin目录（D:\Oracle\Middleware\user_projects\domains\base_domain\bin）。 编辑setDomainEnv.cmd文件，将以下蓝色的地方设置内存大小改成自己需要的。 set WLS_HOME=%WL_HOME%\server if "%JA V A_VENDOR%"=="Sun" ( set WLS_MEM_ARGS_64BIT=-Xms256m -Xmx512m set WLS_MEM_ARGS_32BIT=-Xms256m -Xmx512m ) else ( set WLS_MEM_ARGS_64BIT=-Xms512m -Xmx512m set WLS_MEM_ARGS_32BIT=-Xms512m -Xmx512m ) set MEM_ARGS_64BIT=%WLS_MEM_ARGS_64BIT% set MEM_ARGS_32BIT=%WLS_MEM_ARGS_32BIT% if "%JA V A_USE_64BIT%"=="true" ( set MEM_ARGS=%MEM_ARGS_64BIT% ) else ( set MEM_ARGS=%MEM_ARGS_32BIT% ) set MEM_PERM_SIZE_64BIT=-XX:PermSize=128m set MEM_PERM_SIZE_32BIT=-XX:PermSize=48m if "%JA V A_USE_64BIT%"=="true" ( set MEM_PERM_SIZE=%MEM_PERM_SIZE_64BIT% ) else ( set MEM_PERM_SIZE=%MEM_PERM_SIZE_32BIT% ) set MEM_MAX_PERM_SIZE_64BIT=-XX:MaxPermSize=256m set MEM_MAX_PERM_SIZE_32BIT=-XX:MaxPermSize=128m
内存泄露与内存溢出 1定义 1、内存泄漏：一般可以理解为系统资源（各方面的资源，堆、栈、线程等）在错误使用的情况下，导致使用完毕的资源无法回收（或没有回收）,从而造成那部分内存不可用的情况。 2、内存溢出：指内存不够使用而抛出异常，内存泄露是其形成的原因之一。 2危害 会导致新的资源分配请求无法完成，引起系统错误，最后导致系统崩溃。 3内存泄漏分类 4 内存泄露/溢出发生的区域
5内存溢出异常 6内存溢出常见原因 7发生内存泄露的情形Java内存泄露根本原因是什么呢？
答：长生命周期的对象持有短生命周期对象的引用就很可能发生内存泄露，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是java中内存泄露的发生场景。 具体主要有如下几大类： 7.1 静态集合类引起内存泄露 像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。 例: 解析： 在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身（o=null），那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。 7.2创建过大对象
以上代码运行时瞬间报错。 7.3监听器 在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。 7.4 各种连接 比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。 7.5 内部类和外部模块等的引用 内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。此外程序员还要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如： public void registerMsg(Object b); 这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。 7.6 单例模式 不正确使用单例模式是引起内存泄露的一个常见问题，单例对象在被初始化后将在JVM的整个生命周期中存在（以静态变量的方式），如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露
apache服务器出现内存溢出的解决方法 2011-10-08 14:26 Tomcat内存溢出的原因 在生产环境中tomcat内存设置不好很容易出现内存溢出。造成内存溢出是不一样的，当然处理方式也不一样。 这里根据平时遇到的情况和相关资料进行一个总结。常见的一般会有下面三种情况： 1.OutOfMemoryError： Java heap space 2.OutOfMemoryError： PermGen space 3.OutOfMemoryError： unable to create new native thread. Tomcat内存溢出解决方案 对于前两种情况，在应用本身没有内存泄露的情况下可以用设置tomcat jvm参数来解决。（-Xms -Xmx -XX：PermSize -XX：MaxPermSize） 最后一种可能需要调整操作系统和tomcat jvm参数同时调整才能达到目的。 第一种：是堆溢出。 原因分析： JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。 在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。 Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。 没有内存泄露的情况下，调整-Xms -Xmx参数可以解决。 -Xms：初始堆大小 -Xmx：最大堆大小 但堆的大小受下面三方面影响：
内存这样小小的一个硬件，却是PC系统中最必不可少的重要部件之一。而对于入门用户来说，可能从内存的类型、工作频率、接口类型这些简单的参数的印象都可能很模糊的，而对更深入的各项内存时序小参数就更摸不着头脑了。而对于进阶玩家来说，内存的一些具体的细小参数设置则足以影响到整套系统的超频效果和最终性能表现。如果不想当菜鸟的话，虽然不一定要把各种参数规格一一背熟，但起码有一个基本的认识，等真正需要用到的时候，查起来也不会毫无概念。 内存种类 目前，桌面平台所采用的内存主要为DDR 1、DDR 2和DDR 3三种，其中DDR1内存已经基本上被淘汰，而DDR2和DDR3是目前的主流。 DDR1内存 第一代DDR内存 DDR SDRAM 是Double Data Rate SDRAM的缩写，是双倍速率同步动态随机存储器的意思。DDR内存是在SDRAM内存基础上发展而来的，仍然沿用SDRAM生产体系，因此对于内存厂商而言，只需对制造普通SDRAM的设备稍加改进，即可实现DDR内存的生产，可有效的降低成本。 DDR2内存
第二代DDR内存 DDR2 是DDR SDRAM 内存的第二代产品。它在DDR 内存技术的基础上加以改进，从而其传输速度更快（可达800MHZ ），耗电量更低，散热性能更优良。 DDR3内存 第三代DDR内存
DDR3相比起DDR2有更低的工作电压，从DDR2的1.8V降落到1.5V，性能更好更为省电；DDR2的4bit预读升级为8bit预读。DDR3目前最高能够1600Mhz的速度，由于目前最为快速的DDR2内存速度已经提升到800Mhz/1066Mhz的速度，因而首批DDR3内存模组将会从1333Mhz的起跳。 三种类型DDR内存之间，从内存控制器到内存插槽都互不兼容。即使是一些在同时支持两种类型内存的Combo主板上，两种规格的内存也不能同时工作，只能使用其中一种内存。 内存SPD芯片 内存SPD芯片 SPD(Serial Presence Detect): SPD是一颗8针的EEPROM（Electrically Erasable Programmable ROM 电可擦写可编程只读存储器）, 容量为256字节，里面主要保存了该内存的相关资料，如容量、芯片厂商、内存模组厂商、工作速度等。SPD的内容一般由内存模组制造商写入。支持SPD的主板在启动时自动检测SPD中的资料，并以此设定内存的工作参数。 启动计算机后，主板BIOS就会读取SPD中的信息，主板北桥芯片组就会根据这些参数信息来自动配置相应的内存工作时序与控制寄存器，从而可以充分发挥内存条的性能。上述情况实现的前提条件是在BIOS设置界面中，将内存设置选项设为“By SPD”。当主板从内存条中不能检测到SPD信息时，它就只能提供一个较为保守的配置。 从某种意义上来说，SPD芯片是识别内存品牌的一个重要标志。如果SPD内的参数值设置得不合理，不但不能起到优化内存的作用，反而还会引起系统工作不稳定，甚至死机。因此，很多普通内存或兼容内存厂商为了避免兼容性问题，一般都将SPD中的内存工作参数设置得较为保守，从而限制了内存性能的充分发挥。更有甚者，一些不法厂商通过专门的读
Office2016 Excel的VBA打开显示内存溢出解决办法 1、在excel开发工具中打开查看代码显示内存溢出 刚安装完office2016，但是Excel中的Visual Basic却不能用。原因是 加载路径有问题，以前装了WPS软件，加载路径在WPS文件夹里面。都是WPS 搞的鬼，解决办法是，通过修改注册表的键值到VBE6EXT.OLB所在目录即可。2、解决方法 打开注册表：HKEY_CLASSES_ROOT\TypeLib{0002E157-0000-0000-C000-000000000046}\5.3\0\win32，我右侧数据显示加载路径是 “C:\Users\Administrator\AppData\Local\Kingsoft\WPS Office\10.1.0.5554\office6\vbe6ext.olb”将之修改为你VBE6EXT.OLB文件路径，我的是“C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB”（不知道在哪儿话，直接搜索就好了，VBA6不记得是否是我自己加的了,反正路径下有这个文件，在哪都一样。该方法实测有效） 3.其他方法 （1）卸载重装 点评：这个办法有时候管用，有时候也不管用，视具体情况而定，但个人不建议采用，因为这样的永远都让你学不到东西。 （2）移动VBE6EXT.OLB文件到C:\Program Files\Common Files\microsoft shared\VBA\VBA7 点评：“VBE6EXT.OLB”“VBA7”这两个文件在哪，一搜索便知，据说解决了部分的问题，但有的人电脑里没有VBA7这个文件夹，就无从下手了，亲测新建一个VBA7文件夹貌似也不可以，并非通用方法。
内存溢出和内存泄漏的区别（内存泄漏原因） 内存溢出out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。 内存泄露memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。 memory leak会最终会导致out of memory！ 内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是产生溢出。 内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出！比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出. 以发生的方式来分类，内存泄漏可以分为4类： 1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。 2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。 3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。 4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。 从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会最终消耗尽系统所有的内存。
XXX系统应用服务器内存溢出解决报告 xxxx股份有限公司 2010.9
目录 第一章问题现象与分析 (2) 1.1、问题现象 (2) 1.2、通常导致这种现象的原因 (2) 1.3、xxx社保宕机现象对比分析 (3) 第二章解决方法路线图 (4) 2.1 jvm的调整 (4) 2.2 减少jvm内存使用 (5) 2.2.1 加快db访问速度，减少中间件并发业务量 (5) 2.2.2 限制sql返回结果集 (6) 2.2.3 减少业务会话中存放的对象 (6) 2.3 补救措施 (6) 第三章、解决结果与进一步建议 (6) 3.1 解决结果 (6) 3.2 进一步建议 (7) 第一章问题现象与分析 1.1、问题现象 XXX应用服务器经常有内存溢出、系统没有响应的现象，尤其在每月的月末最为明显。 目前的应用服务器有三种类型，其中ibm和linux应用服务器报告频繁出现内存溢出或没有响应的现象，hp unix应用服务器相稳定。在出现问题期间Weblogic无法响应任何客户端请求，大量请求加载到了这台没有响应的Server上，最后只有杀掉并重启这台应用服务器。 1.2、通常导致这种现象的原因 WLS Server 没响应可能的几种原因：
1、繁重的I/O，呼叫DB时间过长导致中间件内存耗尽，server没有响应。 2、程序死循环，loop－backs，这种情况cpu很忙，系统没有响应。 3、连接到外部server，没响应，由于网络等原因 4、2个以上的执行者同步死锁 5、业务量过大，全部线程都被占用，出现队列等待现象 6、读写本地I/O，发生阻塞 WLS Server 宕机的原因： OutOfMemory JNI程序 jvm的bug os的bug 1.3、xxx社保宕机现象对比分析 ?应用服务器没有响应分析 通过初步判断，对于xxx应用服务器没有响应的情况可以做如下排出法解决： ――程序死循环 这种情况会导致cpu非常繁忙，而通过目前观察，每次系统没响应的时候，cpu没有一直100%忙，另外，对出现问题时的java core分析没有发现这类线程，因此可以基本排除这种可能，。 ――连接到外部server，没响应，由于网络等原因 目前我们的业务基本都是直接通过中间件访问数据，没有通过应用服务器间调用或多数据库调用的，基本排除这种可能。 ――2个以上的执行者同步死锁 这种情况有可能，但比较难找，一般都是业务高峰的时候才有可能出现，跟应用人员了解后得知我们很少使用同步方式实现对资源的共享。另外通过对javacore进行分析，并未发现同步造成的死锁现象。 ――业务量过大，全部线程都被占用，出现队列等待现象 通过观察我们的业务量在高峰时确实很大，但由于我们配置的线程数都很高，尽管出现宕机时也没有达到配置的上线，所以这个方面可以被排除。 ――繁重的I/O，呼叫DB时间过长导致中间件内存耗尽 由于我们经常有新业务变更，尤其近期还有居民医保业务上线，因此I/O问题导致
derwee Java内存泄露模拟及分析解决方法 1.1 实践目标： 1、使用JA V A代码实现模拟内存溢出 2、分析JDK内存溢出的原因 3、总结存在bug的JA V A编码实践 4、总结JVM优化的方法 1.2 模拟内存溢出： 为了方便模拟内存，特意把JVM的内存参数指定为更小（我的本本内存是8G的）。修改eclipse参数文件调用JVM参数： -vmargs -Xms40m（原始是-Xms40m） -Xmx100m（原始是-Xmx384m） 演示JA V A小程序实现原理：使用集合类对象装载大量的Persion对象，每次把new出来的对象加入集合类对象后，更改对象的属性，再从集合类对象中删除该对象。会出现该删除的对象没有被删掉，Persion类对象不断占用内存，导致分配给JVM的内存被耗光。 package .*; /** * * @ClassName: OutOfMemory * @Description: 内存溢出模拟，提出解决方法 * @author yangdw * @date 2012-3-25 下午6:58:49 */ public class OutOfMemory { public static void main(String[] args) { Collection collection = new HashSet(); for(int i=0;i<0;i++) { Persion per = new Persion(i,"yangdw"); (per);
1.2.1equals和hashcode重写原则[2] 1.2.1.1 对equals()应该遵循如下要求 1)对称性：如果(y)返回是“true”，那么(x)也应该返回是“true”。 2)自反性：(x)必须返回是“true”。 3)传递性：如果(y)返回是“true”，而且(z)返回是“true”，那么(x)也应该 返回是“true”。 4)任何情况下，(null)，永远返回是“false”。 5)(和x不同类型的对象)永远返回是“false”。 1.2.1.2 hashCode()的返回值和equals()的关系如下 1)如果(y)返回“true”，那么x和y的hashCode()必须相等。 2)如果(y)返回“false”，那么x和y的hashCode()有可能相等，也有可能不 等。