利用AQTime分析.NET程序内存泄露
1.AQTime简介
AQTime是一款著名的,功能强大的Code Profiler工具,它与TestComplete(自动化测试工具)一样,是同属于AutomatedQA公司旗下的软件测试产品,产品含有完整的性能和内存,资源调试工具集,并支持32位及64位机器上的Windows,.NET和JAVA应用程序,同时还支持VBScript和Jscript 代码调试。
AQTime可以帮助程序员理解程序执行过程中运行情况,它内置了大量的调试方案,以及显示面板帮助调试人员隔离以及消除程序的性能问题以及内存、资源泄漏问题,AQTime即可以作为单独的程序启动也可以集成到Microsoft Visual Studio或者Embarcadero RAD Studio(Delphi和C++ Builder的集成开发环境)运行.
AQTime的主要功能
●性能测试
●内存使用情况监控
●系统资源使用情况监控
●代码覆盖率监控
●兼容性分析
●程序异常,模块加载,函数调用情况监控
AQTime内置有丰富的调试方案，分为5类（Allocation、Coverage、Performance、Static Analysis、Tracing），共14种调试方案工具集，列举如下：
●Performance Profiler 性能调试方案
提供针对程序中任意范围内的程序段或单行代码进行的性能检测。在程序执行期间，工具自动收集运行时的性能表征数据(如调用次数、执行时间、调用与被调用函数、函数调用层次图、执行期间发生的异常情况等等)。此外，工具提供与运行时间、CPU缓存使用等相关的多种计数器[如Elapsed Time、User Time、User+Kernel Time、CPU Cache Misses、Context Switches等]，为了解应用代码级和应用程序级上的性能使用和确定可能存在的性能瓶颈提供详实的参考数据。
●Allocation Profiler 内存使用分析方案
跟踪程序执行过程中对内存资源的使用情况，按类、对象检测并显示程序中对内存资源的使用情况，确定明确或潜在的内存泄漏来源，避免由此造成的程序问题。
●BDE SQL Profiler Delphi的BDE 桌面数据库调试方案
●Coverage Profiler代码覆盖率调试方案
代码覆盖率分析，测试出代码在运行过程中的执行情况，可以帮助查找出程序中的无用代码。
●Exception Trace Profiler异常跟踪方案
监测程序运行期间出现的预知和未知异常，并将异常在源代码中进行定位。当程序出现异常时，Event Log窗口会记录下来，再Event View窗口选中异常查看，在Editor窗口中可以查看到当前异常所在的代码位置。
●Light Coverage Profiler轻度代码覆盖率调试方案
●Function Trace Profiler函数跟踪方案
●Load Library Trace 加载库跟踪方案
●Platform Compliance Profiler平台兼容性测试方案
●Reference Count Profiler引用数测试方案
●Resource Profiler资源调试方案
跟踪程序运行期间，对操作系统资源(如fonts, brushes, bitmaps, and other graphic components, registry, COM objects, print spooler,)的使用情况（如某时间片内,程序本身开销的系统资源、因这些资源带来的内存和CPU开销、来自于这些资源使用中出现的错误）使检测者很容易获知在程序运行期间与之相关系统资源的分配和使用情况。
●Sequence Diagram Link Profiler序列图测试方案
自动识别出待测程序中的函数调用关系，自动生成UML格式时序图，并通过word或visio 格式显示，便于检测者及时检查程序的行为。
●Static Analisys Profiler静态分析方案
静态分析并标识出待测程序的内部结构（如UML时序图、函数间调用关系、存在的循环语句、判断语句、异常处理）和程序规模。
●Unused VCL Units未使用VCL单元测试方案
以上的这么些个调试方案,对于.NET内存调试主题来说, Allocation Profiler 内存使用分析方案最为重要和关键,对应辅助的还有调试系统资源引用泄漏的调试方案-Resource Profiler 资源调试方案。
其他几种测试方案各有其特殊的用途，据悉，技术中心最近正在通过AQTime做ZLHIS的代码覆盖率测试。
“工欲善其事必先利其器“，随着对类似AQTime这种业内各著名测试工具的深入理解和应用，相信会对测试和代码调试工作都会有很大的帮助，大大提高我们软件产品的质量以及提高开发及测试工作的效率。
https://www.doczj.com/doc/9212695119.html,程序内存调试
2.1.建立调试工程
首先建立AQTime工程,因为是做ZLBH的内存分析,这里我需要在AQTime的方案列表中选择”Allocation”调试工具集下的”Allocation Profiler”方案.
选择Profile Entire .NET Code by Classes,下面有三个测试级别:
●by Routines 按方法,以方法或函数作为单位
●by Line 按代码行作为单位
●by Classes 按类作为单位
在”Allocation Profiler”方案只支持By Classes,By Routine,By Line在Performance 和Coverage中支持.
AQTime和其他的Memory Profiler不同的地方是,AQTime可以根据Modules为单位进行调试的,即内存报告监控的范围只限于你所选定的模块，这样方便我们收集数据以及分析定位问题,而模块的范围包括exe,dll,ocx,bpl(delphi的控件文件)四种类型.而我们所熟悉的其他Memory Profiler工具,比如:.Net Memory Profiler,ANTs Memory Profiler,通常只需要指定启动的主程序EXE 文件即可。
通过选择工具栏上的选项，设置“显示所有加载的对象“工具栏选项，取消”只显示项目中指定的对象类型“工具栏选项，将取消默认的只显示加载的模块的设置。
根据实际的操作，推荐不用选中太多的模块，对于像ZLBH这种大型应用，全生命周期收集分析下来，启动就需要几分钟，收集数据会很慢，很慢，而且还会收集一些不需要的垃圾数据，而且在分析的过程中过滤起来也超慢，所以推荐在分析前先控制好模块的范围。
AQTime的这种分模块调试的方式应该是为了适应于其他几种调试方式,比如:代码覆盖调试等,对于内存调试方案的好处在于,有助于按需要跟踪指定的模块的内存占用情况,而不是限制于整个应用程序域下所有的对象.
这里,我们需要将ZLBH程序目录下所有的ZLSoft.BusinessHome命名空间下的Dll文件全部加入到新建的工程下面.
建立好工程后,就可以直接点击”R un”或者按F5热键运行需要调试的程序了.
2.2.监控运行状态
在实际的运行状态下,AQTime可以通过多个视图实时监控程序的运行状态,其中AQTime提供的监控视图有:
●Event View 运行事件视图
EventView视图中记录在被调试程序在运行过程中如下信息:
●模块加载,模块卸载,模块移除,模块激活,模块添加情况
●线程创建,退出情况
●程序异常情况
●进程创建,进程退出情况
●User BreakPoint ,用户设置断言的执行情况
●Monitor 监视器视图
监视器视图显示当前程序的所使用到的类的数量及占用内存情况
在右侧还有程序整体占用内存字节数的动态图，可以动态监控程序一段时间的内存占用变化。
●Disassembler 反汇编视图
用于检查程序Routines的二进制代码并依赖于编译器,只有当选择了”By Routines”选项才会出现Dissembler视图内容。
●Editor 代码编辑器视图
设置了“Project Search Directories”和“Search Directories”之后，AQTime会自动在指定的目录下搜寻代码，选择Routine后，会将当前执行的Routine所在的代码行代码内容显示出来。
●Details 明细视图
明细视图用于显示在报告面板中选中的行所附加的调试信息，每种调试方案对应于不同的明细视图列表，例如：在Allocation Profiler，Detail视图显示以下几列：
Routine Name 从下到到上是当前的方法所在的调用堆栈信息，可以通过调用堆栈信息清晰的看出当前程序的执行路径，以及执行路径所执行的次数和当前方法路径所在的代码行数。
●Call Graph对象关系引用图视图
Call Graph显示对象引用层级，可以通过点击不同的对象遍历出对象引用的路径。
下图为SmartForm的一个实例的对象关系引用图，其中SmartForm.3935624实例被标记为Root=True，表明这个实例对象被根化，对象被根化的原因有以下三个：
1.被全局对象引用
2.被其他的本地变量所引用
3.对象作为一个方法的参数被引用
Root=False的对象表明对象被另一个对象作为属性引用。
Call Tree 对象引用树视图
该视图只限于托管代码，对象引用树视图显示两个页卡：“References To“和”Reference From “，”References To”表示的是引用到当前对象的其他对象的信息，“References From”以指定对象为起点，当前对象所引用到的对象。
2.3.实际调试
以上对AQTime调试步骤以及监控方法做了些探索，实际运用还是需要通过有目的的实际调试分析过程来总结经验和方法。下面通过几个对常见造成内存泄漏问题的现象进行分析如下：2.3.1.自定义事件-委托造成的内存泄漏
委托和自定义事件在.NET编程中重要的特性之一，委托（Deletgate）是.NET事件机制的关
键，但是如果使用不当则会造成隐性的内存泄漏问题，发生这种情况的主要场景为需要添加Eventhandler到一个Event上，使用完后又忘了去移除它，导致事件中的对象无法被释放掉。
上图描述的是一个对象定义了一个事件，新建一个Form窗体并挂接到这个事件上，当关闭这个Form窗体后，应该会被释放并被GC回收，而实际上，这个事件的代理仍然保留着对这个Form对象的强引用从而导致不能被正常回收，导致内存泄漏。
对应的实验的代码如下：
新建Form2窗口，并添加如下代码
定义一个TestEventClass类
然后在Form1上通过按钮点击事件Show或ShowDialog函数显示Form2。
OK！准备就绪，开始实验，用AQTime设置好“Allocation Profiler”，并选中“Profile Entire .NET Code By Class”,执行实验程序，首先通过Form1上的一个Button，执行Form2的弹出然后关闭Form2。完成后,执行AQTime的“Get Result”得到收集到的实例如下：
可以看到Form2在四次打开和关闭后，Live Count仍然为4，说明Form2在关闭后并没有被回收。
在看AQTime的Call Tree视图，可以看到Form2仍然被TestEventClass.2868实例所引用到，从而导致Form2本身及其所引用的其他对象无法被正常回收。
出现这种情况的原因是，将一个生命周期较短的对象（Form2）注册到一个生命周期较长（Form1 ）的某个事件（TestEventClass）上，两者便无形之间建立一个引用关系（Form1引用Form2）。这种引用关系导致GC在进行垃圾回收的时候不会将Form2是为垃圾对象，最终使其常驻内存（或者说将Form2捆绑到Form1上，具有了和Form1一样的生命周期）。同理，静态事件也会出现类似的内存泄漏问题。
用一个图表示，如下：
.NET的Delegate对象同样可以分解成两个部分：委托的功能（Method）和目标对象（Target）,Target即委托的对象,在例子中DoEventHandler的Target就是Form2,从上图中可以看到TestEventClass的DoEventHanlder的Target对Form2造成了强引用。
解决的方法有两个，第一个就是通过对DoEventHandler加入-=卸载所加载的事件，加入下面一行代码
第二个方法就是采用WeakReference(弱引用)机制,让EventHandler通过WeakReference的方式与事件监听者(Form2)建立弱引用关系,当不用到事件监听者的时候使其能够被垃圾回收,至于代码如何编写,请兴趣的读者可以参考网文《Solving the Problem with Events: Weak Event Handlers》，这里就不再赘述。
2.3.2.非托管资源造成的内存泄漏
在.NET开发中容易被忽视，引起内存泄漏通常存在于以下三种情况：
1.对象被引用而没有被释放
2.没有释放非托管资源
3.没有释放非托管资源封装对象
上个章节描述的EventHanlder和Delegate造成的内存泄漏就属于第一类，之所以要单独拿出来叙述是因为.NET事件和代理造成的内存泄漏相对于静态变量的根化引用更容易被忽略且不好被识别出来。第2类和第3类同属于系统资源类型造成的内存泄漏，但是又有所区别。
第二类是指通过本地API函数与托管对象进行交互（比如：通过P/Invoke方式调用本地DLL，DLLImport声明静态外部函数和COM Interop）所用到的非托管资源。
例如：当通过DLL Import调用API函数GetDC函数时忘了调用ReleaseDC去释放设备句柄造成4个字节的内存泄漏。
再如：智能文档中使用的Word以及导出EXCEl功能用到的Office的COM非托管组件，在关闭时GC不能识别COM组件而造成有时候无法对COM对象进行释放，这时候可以通过以下两个InteropServices函数进行释放
●System.Runtime.InteropServices.Marshal.ReleaseComObject(comObject);
●System.Runtime.InteropServices.Marshal.FinalReleaseComObject(comObject);
上次在敏捷交流了内存相关事项问题后，给大家留了几道思考题，其中第一道题是“数据库连接SqlConnection是不是非托管资源，为什么？”，有些人的回答是“肯定”，之所以有这样回答是因为大家所了解的非托管资源的经典认知就是数据库连接、文件、网络连接都是非托管资源，有人认为SqlConnection就是数据库连接，其实不然，.NET对某些非托管资源提供一种包装类，SqlConnection就是这种，包装类的源（WrapSource）才真正是托管资源，它管理了非托管资源，而它本身确实托管的。
.NET GDI Plus中常用的Drawing命名空间下的类很多就是这种包装类型，现将常用的几种非托管包装类列举如下：
识别这种包装类型的主要方法就是通过MSDN查询是否该对象继承于System.MarshalByRefObject类。
做一个实验来测试Graphics的释放，新建一个Form对象，在Form对象的Paint事件里，写入以下代码，用于在Form2上绘制。
运行起来发现，不停的移动Form2，对应刷新Form2的Paint事件，在内存管理器里面可以看到实验程序的内存会不停的增长，这说明这时候已经产生了内存泄漏了。
启动AQTime，并启用Resource Profiler调试方案，运行程序，隔一段时间调用“Get Result”收集数据。
第一次收集数据，GpGrahics对象的LiveCount =3；
第二次收集数据，GpGrahics对象的LiveCount =21；
GpGraphics对象的持续增长说明，GpGraphics造成了内存泄漏，再利用.NET Memory Profiler 捕捉内存Heap快照。
显示方法中的Bitmap、Graphics、LinearGradientBrush三种类型出现了“Undisposed Instances”警告。
这里，因为Graphics没有释放导致Grahics上引用的Bitmap，以及Bimap上的LinearGradientBrush对象都没有被及时释放，造成内存泄漏。
将代码修改如下：
再运行AQTime和.NET Memory Profiler，可以看到.NET Memory Profiler的警告消除了，AQTime显示GpsGraphics的Live Count一直是1，不再会增加。
由此得知，.NET中的Drawing托管对象使用也会造成内存泄漏，以上泄漏的问题很容易被忽视，因为如果这种泄漏内存的增长量不大，在整个程序运行时显得微不足道，而不容易察觉，另外因为Form作为继承了Idisposable接口的控件容器，在其关闭时会自动调用其每个被引用对象的Dispose方法，所以最后Form也会帮你回收的。Form的Dispose方法如下：
通常，好的编程习惯要求程序员在使用完非托管资源的对象后应尽快释放不再使用的对象和资源来避免潜在的内存泄漏。
释放这种包装对象的方法有3种：
●显式通过Dispose方法释放（推荐）
例如：font.Dispose();
●隐式通过Using语句释放（推荐）
Using (Font font = new Font(https://www.doczj.com/doc/9212695119.html,, currentSize, Label1.Font.Style))
{
}
●通过Finalization方法（不推荐）
不推荐，因为用 Finalize 方法回收对象使用的内存需要至少两次垃圾回收，当垃圾回收器回收时，它只回收没有终结器(Finalize方法)的不可访问的内存，这时他不能回收具有终结器(Finalize方法)的不可以访问的内存。
注：什么是非托管资源
3.遇到的几个问题
完成本文的过程不能算是一蹴而就，其中也曾出现过困惑和误解，随着.NET本身版本的不断升级和完善，有些资料所描述的内容部分已经成为了过去时，如果是形而上学只会是认知上的“刻舟求剑”，有的时候由于一个测试参数的设置都可能导致实验结果的不正确，造成错误的认知。以下就过程中出现的几个问题拿出来与大家分享：
3.1.不要在Debug模式下调试
VS提供了2种运行模式：Debug和Release，当按F5运行程序时，VS默认的是Debug模式，运行，VS为了让Debug更快速会创建一个与程序名相同的Vshost.exe（VS Debug Host Process）文件，当通过Debug调试程序时，程序是通过.vshost启动的，在程序的运行过程中，Vshost会与VS进行交互，保持程序上的堆栈和函数信息以供VS调试内存中的变量。这样造成调试程序时，虽然程序应该是释放了内存，但是由于Vshost为了收集堆栈的信息方便调试，会将释放的过程滞后，导致用调试工具抓取的对象快照里面仍然是存活的对象，从而得到了错误的结果。
所以，调试程序内存应在Release模式下，避免不必要的干扰，保证数据结果的正确性。3.2.最好自己GC
由于.NET 回收的LAZY Calcuation机制，在收集数据时，.NET还没有来得及去做一次GC，在收集的数据里还保留着已经标记成回收但是还来得及回收的对象，一般的内存调试工具会在收集数据之前自动的去做一次GC，例如：.NET Memory Profiler，而AQTime则根本不会自动的去做GC，需要手工去调用“Force GC Collection”功能。另外，.NET Memory Profiler在通过“Attach Process”的方式调试程序时，也是不会去自动调用GC的。因此，在写调试程序时，针对不同的工具为了保证收集正确的数据，应在对应的位置通过添加代码GC.Collect()去强制进行一次GC,当然，在实际的代码中是禁止写GC.Collect()的。
4.总结
本文通过介绍AQTime内存调试和资源调试功能在.NET程序内存调试中实际运用，向大家推荐了一款新的调试工具，其实，AQTime针对于.NET的内存调试并不是最佳选择，相比之
下，.NET Memory Profiler工具会更好一些，至少，AQTime启动对.NET的程序调试的运行效率确实无法让人接受。但是，AQTime对于编译执行的程序调试肯定是比.NET这种解释执行的程序调试起来要快的多，而且，AQTime拥有的多种调试方案以及按Module调试的设计，可以作为.NET Memory Profiler工具的一种补充选择。由于此次没有对AQTime的针对.NET程序做性能和代码覆盖率测试，也无法确定其对ZLBH测试的实用性，但是对于技术中心做ZLHIS的全面深入的测试，AQTime确实是值得一提的。
xxxx运维服务工作总结
目录 1概述....................................................................... 2运维项目背景............................................................... 3运维目标................................................................... 4运维人员配备............................................................... 5运维工作总结............................................................... 5.11-8月份................................................................... 5.1.1XXXX系统测试与部署 ................................................... 5.1.2协助XXXX机房搬迁..................................................... 5.1.3二线专家支撑.......................................................... 5.1.4XXXX系统优化 ......................................................... 5.29-12月份.................................................................. 5.2.1系统运维支撑.......................................................... 系统巡检方式............................................................ 远程方式............................................................. 现场方式............................................................. 系统维护巡检内容........................................................ 远程方式巡检内容..................................................... 现场方式巡检内容.................................................... 系统运行分析............................................................ 系统CPU分析......................................................... 系统内存分析......................................................... 系统硬盘空间分析..................................................... 系统进程运行分析..................................................... 系统故障分析......................................................... 现网作业工作............................................................ 5.2.2业务协维.............................................................. 系统业务管理............................................................ 运营支撑内容............................................................ ZS业务客户服务与支持..................................................... 运营数据分析............................................................ 5.2.3专家服务.............................................................. 运维体系的建立.......................................................... 输出文档 ............................................................... 运维、系统二线支撑......................................................
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:
运维项目工作总结参考-CAL-FENGHAI.-(YICAI)-Company One1
xxxx运维服务工作总结
目录
1概述 2011年对于XXXX来说是具有历史意义的一年，XXXX成功上线到接入第一个业务系统：集团采购门户系统，揭开了XXXXXXXX认证的一个新的篇章，XXXX 公司作为XXXX的运维服务方，在历史的一年即将过去，通过对XXXX运维工作进行年度总结，从中发现工作中的不足，在以后的工作中逐渐改善。 2运维项目背景 3运维目标 XXXX公司为XXXX系统提供运行维护服务包括，XXXX软件系统、系统相关的主机设备、操作系统、数据库和存储设备的运行维护服务，保证XXXX系统整体的正常运行，降低整体管理成本，提高XXXX系统的整体服务水平。同时根据日常维护的数据和记录，提供XXXX系统的整体建设规划和建议，更好的为XXXX发展提供有力的支持。 同时XXXX公司为XXXX系统提供业务协维服务，包括业务系统接入前期业务支撑、业务系统接入后期业务支撑，为业务系统提供专业的业务指引、开发指引，方便各业务系统快速接入XXXX系统。 XXXX系统的组成主要可分为两类：硬件设备和软件系统。硬件设备包括网络设备、安全设备、主机设备、存储设备等；软件设备可分为操作系统软件、典型应用软件（如：数据库软件、中间件软件等）、业务应用软件等。 XXXX公司通过运行维护服务的有效管理来提升XXXX系统的服务效率，结合用户现有的环境、组织结构、IT资源和管理流程的特点，从流程、人员和技术三方面来规划用户的网络信息系统的结构。将用户的运行目标、业务需求与IT服务的相协调一致。 XXXX公司提供的服务的目标是，对用户现有的XXXX系统基础资源进行监控和管理，及时掌握网络信息系统资源现状和配置信息，反映XXXX系统资源的可用性情况和健康状况，创建一个可知可控的IT环境，从而保证XXXX系统的各类业务应用系统的可靠、高效、持续、安全运行。 4运维人员配备 XXXX运维人员梯队结构 人的因素是决定运维服务好坏的最重要的因素，合理的人力配置能够提高运维的质量和效率，保障运维工作的顺利开展, XXXX公司通过人力资源的整合
内存泄漏检测方法 ?对于不同的程序可以使用不同的方法来进行内存泄漏的检查，还可以使用一些专门的工具来进行内存问题的检查，例如MemProof、AQTime、Purify、BundsChecker 等。 ?也可以使用简单的办法：利用Windows自带的Perfmon来监控程序进程的handle count、Virtual Bytes和Working Set 3个计数器。 Handle Count记录了进程当前打开的句柄个数，监视这个计数器有助于发现程序是否存在句柄类型的内存泄漏； Virtual Bytes记录了程序进程在虚拟地址空间上使用的虚拟内存的大小，Virtual Bytes一般总大于程序的Working Set，监视Virtual Bytes可以帮助发现一些系统底层的问题； Working Set记录了操作系统为程序进程分配的内存总量，如果这个值不断地持续增加，而Virtual Bytes却跳跃式地增加，则很可能存在内存泄漏问题。 堆栈内存泄漏 ?堆栈空间不足会导致在受托管的情况下引发StackOverflowException类型的异常，线程泄漏是堆栈内存泄漏的其中一种。线程发生泄漏，从而使线程的整个堆栈发生泄漏。 ?如果应用程序为了执行后台工作而创建了大量的工作线程，但却没有正常终止这些线程，则可能会引起线程泄漏。 一个堆栈内存泄漏的例子： private void button1_Click(object sender, EventArgs e) { // 循环启动多个线程 for (int i = 0; i < 1500; i++) { Thread t = new Thread(new ThreadStart(ThreadProc)); t.Start(); } } static void ThreadProc() { Console.WriteLine("启动Thread #{0}
项目进行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% :
面向对象的思想特点 A:是一种更符合我们思想习惯的思想 B:可以将复杂的事情简单化 C:将我们从执行者变成了指挥者 面向对象： 我们怎么才能更符合面向对象思想呢? A:有哪些类呢? B:每个类有哪些东西呢? C:类与类直接的关系是什么呢? 开发，设计，特征 面向对象开发 就是不断的创建对象，使用对象，指挥对象做事情。 面向对象设计 其实就是在管理和维护对象之间的关系。 面向对象特征 封装(encapsulation) 继承(inheritance) 多态(polymorphism) 继承：把多个类中相同的成员给提取出来定义到一个独立的类中。然后让这多个类和该独立的类产生一个关系，这多个类就具备了这些内容。这个关系叫继承。 继承的好处： A:提高了代码的复用性 B:提高了代码的维护性 C:让类与类产生了一个关系，是多态的前提 继承的弊端： A:让类的耦合性增强。这样某个类的改变，就会影响其他和该类相关的类。 原则：低耦合，高内聚。 耦合：类与类的关系 内聚：自己完成某件事情的能力 B:打破了封装性 Java中继承的特点 A:Java中类只支持单继承 B:Java中可以多层(重)继承(继承体系) 继承的注意事项： A:子类不能继承父类的私有成员 B:子类不能继承父类的构造方法，但是可以通过super去访问 C:不要为了部分功能而去继承
多态：同一个对象在不同时刻体现出来的不同状态。 多态前提： A:有继承或者实现关系。 B:有方法重写。 C:有父类或者父接口引用指向子类对象。 多态中的成员访问特点 A:成员变量 编译看左边，运行看左边 B:构造方法 子类的构造都会默认访问父类构造 C:成员方法 编译看左边，运行看右边 D:静态方法 编译看左边，运行看左边 多态的好处 提高了程序的维护性(由继承保证) 提高了程序的扩展性(由多态保证) 多态的弊端 不能访问子类特有功能 静态的特点： A:随着类的加载而加载 B:优先与对象存在 C:被类的所有对象共享 这其实也是我们判断该不该使用静态的依据。 D:可以通过类名调用 静态变量和成员变量的区别 A:所属不同 静态变量：属于类，类变量 成员变量：属于对象，对象变量，实例变量 B:内存位置不同 静态变量：方法区的静态区 成员变量：堆内存 C:生命周期不同 静态变量：静态变量是随着类的加载而加载，随着类的消失而消失 成员变量：成员变量是随着对象的创建而存在，随着对象的消失而消失D:调用不同 静态变量：可以通过对象名调用，也可以通过类名调用 成员变量：只能通过对象名调用
JAVA内存溢出 解决方案 1. 内存溢出类型 1.1. https://www.doczj.com/doc/9212695119.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/9212695119.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位的就不会有限制了。
如何测试客户端软件的内存泄露客户端软件包括C/S系统的客户端和B/S系统中的客户端控件，当用户使用客户端软件时，如果发现我们的软件会吃内存，那是很丢面子的事，有哪些好的测试方法呢？希望大家能踊跃提出自己的看法。 会员huior的精彩回答：如何发现客户端软件中的内存泄露？我的看法是：检测内存泄漏的问题应该尽早进行，它绝不应该是系统测试时的主要目标。也就是说，检查是否存在内存泄漏，应该从编码时就要考虑，单元测试和集成测试时要重点检查。如果前期没有考虑，等到了系统测试才想起检查或者才发现泄漏，为时已晚，此时再去定位泄漏的位置，太难太难了，它可能会让你的交付日期delay不确定的时间。 最近看了一些自动错误预防（AEP）的理论，我深受启发。作为测试人员的我们，从“发现错误”转变到“帮助开发人员预防错误”，这将是一个巨大的转变。所以说，下面我的答案中的第一点，我先说如何预防内存泄漏的问题，然后再讲如何发现。如何在开发过程中有效预防内存泄漏？ 第一步：遵循“好”的编程规则“好”的编程规则是各位前辈经验和教训的集合，好的编程规则堪称开发者的“圣经”。遵循统一的编程规则，可以让开发新手少走好多弯路，可以让项目整体的质量维持一个起码的“质量底线”。有关内存泄漏方面的规则主要是“内存管理”方面的，举几个简单的，如下x用malloc或new申请内存之后，立即检查指针值是否为NULL（防止使用指针值为NULL的内存），×动态内存的申请与释放是否配对（防止内存泄漏），x malloc 语句是否正确无误？例如字节数是否正确？类型转换是否正确×是否出现野指针，例如用free或delete释放了内存之后，忘记将指针设置为NULL。 第二步：积极主动检测“内存泄漏”，严格遵循好的编程规则，可以让程序员在代码中尽量少的引入bug，但一旦不小心引入了，怎么办？这就要求我们在单元测试和集成测试中严格把关。在这个阶段，单靠程序员或者测试员通过“代码走查”的方式检查内存泄漏，客户的实践和我的经验告诉我，这是不切实际的，无论效率还是时间。如果能够借助于一些专业的工具的话，情况可能就不一样了。 如果你的程序是用Visual C++ 6.0开发，那么Numega的BoundsChecker将是你检测“内存泄漏”最好的选择，如果是Visual C++.NET，可以试一下Compuware的DevPartner。如果你的程序基于Unix或者Linux平台，使用C或者C++，可以考虑一下开源的工具valgrind，我的朋友跟我说，它在一定程度上比Rational的Purify更出色。上面的工具都要求程序能够动态运行起来，而且测试用例需要你自己准备。 如果你正处于单元测试或集成测试阶段，程序代码量已经足够大，而且还不能够动态运行，要尽早检测代码中的“内存泄漏”问题，该怎么办？此时你可以试用一下目前最新的静态分析技术：×它不要求代码能够动态运行，×也不需要你来编写测试用例，×只需要代码能够正常编译，就可以发现代码只有在执行过程中才出现的错误，当然也包括内存泄漏。 这方面的工具有Klocwork的K7，Coverity的SQS，以及C++test中的BugDetective，其中最“物美价廉”的就是c++test的BugDetective。 如何发现客户端软件的“内存泄漏”？如果开发过程中已经按照我上面提到的去做，相信发布后的程序存在“内存泄漏”的可能性几乎为零。如果开发过程已经到了后期，系统测试已经开始做了，还要发现内存泄漏，这个时候我希望你能够拿到源代码。如果有源代码，你还可以考虑第二步，借助专业的工具协助，虽然可能效果不一定特别理想，但总比下面我提到的方法更好一些。 当然作为测试人员，通常会碰到“需要在系统测试阶段检测是否有内存泄漏，而且没有
彻底解决Weblogic报出https://www.doczj.com/doc/9212695119.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
KEIL编译错误信息表 错误代码及错误信息错误释义 error 1: Out of memory 内存溢出 error 2: Identifier expected 缺标识符 error 3: Unknown identifier 未定义的标识符 error 4: Duplicate identifier 重复定义的标识符 error 5: Syntax error 语法错误 error 6: Error in real constant 实型常量错误 error 7: Error in integer constant 整型常量错误 error 8: String constant exceeds line 字符串常量超过一行 error 10: Unexpected end of file 文件非正常结束 error 11: Line too long 行太长 error 12: Type identifier expected 未定义的类型标识符 error 13: Too many open files 打开文件太多 error 14: Invalid file name 无效的文件名 error 15: File not found 文件未找到 error 16: Disk full 磁盘满 error 17: Invalid compiler directive 无效的编译命令 error 18: Too many files 文件太多 error 19: Undefined type in pointer def 指针定义中未定义类型 error 20: Variable identifier expected 缺变量标识符 error 21: Error in type 类型错误 error 22: Structure too large 结构类型太长 error 23: Set base type out of range 集合基类型越界 error 24: File components may not be files or objectsfile分量不能是文件或对象error 25: Invalid string length 无效的字符串长度 error 26: Type mismatch 类型不匹配 error 27：error 27：Invalid subrange base type 无效的子界基类型 error 28：Lower bound greater than upper bound 下界超过上界 error 29：Ordinal type expected 缺有序类型 error 30：Integer constant expected 缺整型常量 error 31：Constant expected 缺常量 error 32：Integer or real constant expected 缺整型或实型常量 error 33：Pointer Type identifier expected 缺指针类型标识符 error 34：Invalid function result type 无效的函数结果类型 error 35：Label identifier expected 缺标号标识符 error 36：BEGIN expected 缺BEGIN error 37：END expected 缺END error 38：Integer expression expected 缺整型表达式
内存泄露与内存溢出 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正常回收，导致内存泄露
在IE下的JS编程中，以下的编程方式都会造成即使关闭IE也无法释放内存的问题，下面分类给出： 1、给DOM对象添加的属性是一个对象的引用。范例： var MyObject = {}; document.getElementById('myDiv').myProp = MyObject; 解决方法： 在window.onunload事件中写上: document.getElementById('myDiv').myProp = null; 2、DOM对象与JS对象相互引用。范例： function Encapsulator(element) { this.elementReference = element; element.myProp = this; } new Encapsulator(document.getElementById('myDiv')); 解决方法： 在onunload事件中写上: document.getElementById('myDiv').myProp = null; 3、给DOM对象用attachEvent绑定事件。范例： function doClick() {} element.attachEvent("onclick", doClick); 解决方法： 在onunload事件中写上: element.detachEvent('onclick', doClick); 4、从外到内执行appendChild。这时即使调用removeChild也无法释放。范例： var parentDiv = document.createElement("div"); var childDiv = document.createElement("div"); document.body.appendChild(parentDiv); parentDiv.appendChild(childDiv); 解决方法： 从内到外执行appendChild: var parentDiv = document.createElement("div"); var childDiv = document.createElement("div"); parentDiv.appendChild(childDiv);
一、软件测试流程 整体流程：测试需求分析，测试计划编写，测试用例编写，测试执行，缺陷记录，回归测试，判断测试结束，测试报告提交。 测试流程依次如下： 1.需求：阅读需求，理解需求，与客户、开发、架构多方交流，深入了解需求。--testing team。一般而言， 需求分析包括软件功能需求分析、测试环境需求分析等 2.测试计划: 根据需求估算测试所需资源（人力、设备等）、所需时间、功能点划分、如何合理分配安排资 源等。---testing leader or testing manager。测试目的、测试环境、测试方法、测试用例、测试工具 3.用例设计：根据测试计划、任务分配、功能点划分，设计合理的测试用例。---testing leader, senior tester 4.执行测试：根据测试用例的详细步骤，执行测试用例。--every tester(主要是初级测试人员) 5.执行结果记录和bug记录：对每个case记录测试的结果，有bug的在测试管理工具中编写bug记录。--every tester(主要是初级测试人员) 6.defect tracking（缺陷跟踪）：追踪leader分配给你追踪的bug.直到 bug fixed。--every tester 7.测试报告：通过不断测试、追踪，直到被测软件达到测试需求要求，并没有重大bug. 8.用户体验、软件发布等…… 总结：项目立项后，开始写测试计划，根据需求编写测试需求，根据测试需求编写测试用例，根据测试用例执行测试，把没用通过的测试用例写成测试缺陷报告，进行回归测试，直到测试的结束编写测试总结，这每个步骤都需要审核通过。 二、软件测试方法 1、黑盒测试 概念：完全不考虑程序或软件的内部逻辑结构和处理过程的情况下，根据需求分析编写并执行测试用例，在程序或软件的界面上进行测试。 主要目的：（1）是否有不正确的或者遗漏的功能。（2）能都正确输入和输出结果。（3）是否有数据结构错误或外部信息访问错误。（4）性能上是否满足要求。（5）是否有初始化或终止行错误。 优点：（1）即使程序发生变化，之前的测试用例依然可以使用；（2）测试用例和软件开发可以同时进行，加快了测试和开发的速度。 局限性：（1）难以查找问题的原因和位置；（2）黑盒测试的依据是需求分析，所以无法发现需求分析上的错误。 测试方法： （1）等价类划分 包括有效等价类（符合需求规格说明）和无效等价类（违反需求规格说明）。 a)确定输入取值范围：可以确定一个有效等价类和两个无效等价类 b)确定输入某个值：可以确定一个有效等价类和两个无效等价类
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：最大堆大小 但堆的大小受下面三方面影响：
Linux下利用Valgrind工具进行内存泄露检测和性能分析 [日期：2012-06-25] 来源：Linux社区作者：yanghao23 Valgrind通常用来成分析程序性能及程序中的内存泄露错误 一 Valgrind工具集简绍 Valgrind包含下列工具： 1、memcheck：检查程序中的内存问题，如泄漏、越界、非法指针等。 2、callgrind：检测程序代码的运行时间和调用过程，以及分析程序性能。 3、cachegrind：分析CPU的cache命中率、丢失率，用于进行代码优化。 4、helgrind：用于检查多线程程序的竞态条件。 5、massif：堆栈分析器，指示程序中使用了多少堆内存等信息。 6、lackey： 7、nulgrind： 这几个工具的使用是通过命令：valgrand --tool=name 程序名来分别调用的，当不指定tool 参数时默认是 --tool=memcheck 二 Valgrind工具详解 1.Memcheck 最常用的工具，用来检测程序中出现的内存问题，所有对内存的读写都会被检测到，一切对malloc、free、new、delete的调用都会被捕获。所以，它能检测以下问题： 1、对未初始化内存的使用； 2、读/写释放后的内存块； 3、读/写超出malloc分配的内存块； 4、读/写不适当的栈中内存块； 5、内存泄漏，指向一块内存的指针永远丢失； 6、不正确的malloc/free或new/delete匹配； 7、memcpy()相关函数中的dst和src指针重叠。 这些问题往往是C/C++程序员最头疼的问题，Memcheck能在这里帮上大忙。 例如： #include
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文件夹貌似也不可以，并非通用方法。