内存泄露的问题,用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 将内存使用的详细情况输出到mem.dat 文件
jmap -dump:live,format=b,file=heap.bin <pid>
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 区已使用空间的百分比
O — 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 [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
<collector>GC收集器的名称
<starting occupancy1> 新生代在GC前占用的内存
<ending occupancy1> 新生代在GC后占用的内存
<pause time1> 新生代局部收集时jvm暂停处理的时间
<starting occupancy3> JVM Heap 在GC前占用的内存
<ending occupancy3> JVM Heap 在GC后占用的内存
<pause time3> GC过程中jvm暂停处理的总时间
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]
java.lang.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的优化可以通过现在很多图形工具来做，也可以类似于我这样采用最原始的分析方式，好处就是任何时间任何地点只要知道原理就可以分析无需借助外部工具。原始的总是最好的^_^。
jstat -gcutil -h5 11597 4s 100
查gc
jstack -l 11597
查进程下线程
相关推荐
jmap主要用于生成堆内存转储文件，这对于分析内存泄漏等问题非常重要。此外，jmap还可以用于查看堆内存的总体使用情况。 ##### 常用命令 - **生成堆转储**：`jmap -dump:format=b,file=<file_name> <pid>` - **查看...
JDK内置的命令行工具，如jps、jstat、jmap、jhat等，是分析JVM状态和诊断问题的实用工具。图形界面工具，如JVisualVM，提供了更直观的方式来监控和分析JVM。JDWP（Java Debug Wire Protocol）则用于远程调试，而JMX...
* jmap -dump:format=b,file=heapDump 3331：将内存使用的详细情况输出到文件，之后一般使用其他工具进行分析。 5. jhat命令 jhat命令（Java Heap Analysis Tool），是一个用来分析java的堆情况的命令。使用jmap...
问题描述： 停车场内只有一个可停放n辆汽车的狭长通道，且只有一个大门可供汽车进出。汽车在停车场内按车辆到达时间的先后顺序，依次由北向南排列（大门在最南端，最先到达的第一辆车停放在停车场的最北端），若车场内已停满n辆汽车，则后来的汽车只能在门外的便道上等候，一旦有车开走，则排在便道上的第一辆车即可开入； 当停车场内某辆车要离开时，在它之后开入的车辆必须先退出车场为它让路，待该辆车开出大门外，其它车辆再按原次序进入车场，每辆停放在车场的车在它离开停车场时必须按它停留的时间长短交纳费用。试为停车场编制按上述要求进行管理的模拟程序。 1.基本要求 （1）以栈模拟停车场，以队列模拟车场外的便道，按照从终端读入的输入数据序列进行模拟管理。 （2）每一组输入数据包括三个数据项：汽车“到达”或“离去”信息、汽车牌照号码及到达或离去的时刻，对每一组输入数据进行操作后的输出数据为：若是车辆到达，则输出汽车在停车场内或便道上的停车位置；若是车离去；则输出汽车在停车场内停留的时间和应交纳的费用（在便道上停留的时间不收费）。 （3）栈以顺序结构实现，队列以链表实现。 2.重点难点 重点：针对停车场问题的特点，利
精选毕设项目-人民好公仆小程序（生活+便民+政务）
精选毕设项目-相册；处理用户信息
精选毕设项目-喵喵小说
精选毕设项目-图片预览带后端
精选项目-爱靓女带后台
在科技与司法的交响曲中，智慧法院应运而生，成为新时代司法服务的新篇章。它不仅仅是一个概念，更是对法院传统工作模式的一次深刻变革。智慧法院通过移动信息化技术，为法院系统注入了强大的生命力，有效缓解了案多人少的矛盾，让司法服务更加高效、便捷。 立案、调解、审判，每一个阶段都融入了科技的智慧。在立案阶段，智慧法院利用区块链技术实现可信存证，确保了电子合同的合法性和安全性，让交易双方的身份真实性、交易安全性得到了有力见证。这不仅极大地缩短了立案时间，还为后续审判工作奠定了坚实的基础。在调解阶段，多元调解服务平台借助人工智能、自然语言处理等前沿技术，实现了矛盾纠纷的快速化解。无论是矛盾类型的多元化，还是化解主体的多元化，智慧法院都能提供一站式、全方位的服务，让纠纷解决更加高效、和谐。而在审判阶段，智能立案、智能送达、智能庭审、智能判决等一系列智能化手段的应用，更是让审判活动变得更加智能化、集约化。这不仅提高了审判效率，还确保了审判质量的稳步提升。 更为引人注目的是，智慧法院还构建了一套完善的执行体系。移动执行指挥云平台的建设，让执行工作变得更加精准、高效。执行指挥中心和信息管理中心的一体化应用，实现了信息的实时传输和交换，为执行工作提供了强有力的支撑。而执行指挥车的配备，更是让执行现场通讯信号得到了有力保障，应急通讯能力得到了显著提升。这一系列创新举措的实施，不仅让执行难问题得到了有效解决，还为构建诚信社会、保障金融法治化营商环境提供了有力支撑。智慧法院的出现，让司法服务更加贴近民心，让公平正义的阳光更加温暖人心。
西门子1200与3台台达DTK温控器通讯程序 功能：实现西门子1200 PLC对3台台达DTK温控器进行485通讯控制，在触摸屏上设定温度，读取温度 器件：西门子1200 1214DC DC DC.昆仑通态TPC7062Ti ，西门子KTP700 Basic PN，台达DTK 4848V12温控器。 说明：的是程序，带详细注释程序，西门子触摸屏程序，PLC设置和温控器设置，接线说明书。 #SIEMENS 西门子
机械设计电阻绕线焊线一体机sw18全套技术资料100%好用.zip
VB6编写的上位机源码，可实时显示曲线图，带有数据库，可以进行历史数据的保存 及 查看历史采集数据。
精选毕设项目-新浪读书
jQuery+Slick插件实现游戏人物轮播展示切换特效源码是一款通过背景图片的切换来显示不同的人物效果，轮播效果通过slick幻灯片插件来制作。效果非常棒，有需要的朋友可以直接下载使用，适应各大网站
精选毕设项目-地图查找附件
（蛐蛐voc数据）农作物病虫害识别目标检测数据集，VOC格式，蛐蛐数据集，纯手动标注，用来进行目标检测代码训练的数据。
MATLAB Simulink仿真模型 双馈风机并网频率控制仿真模型，利用下垂控制与惯性控制结合的综合惯性控制，实现电力系统的频率稳定，两台同步发电机组，具体参数可自行调节，频率波形比较可利用matlab工作区画出。
一、结题报告的类型及主要结构 结题报告是一种专门用于科研课题结题验收的实用性报告类文体，也叫研究报告。它是研究者在课题研究结束后对科研课题研究过程和研究成果进行客观、全面、实事求是的描述，是课题研究所有材料中最主要的材料，也是科研课题结题验收的主要依据。 一篇规范、合格的结题报告，需要回答好3个问题：一是“为什么要选择这项课题进行研究？”二是“这项课题是怎样进行研究的？”三是“课题研究取得哪些研究成果？” 基本结构大致包括以下部分： 第一个问题 “为什么要选择这项课题进行研究？” 1．课题提出的背景；2．课题研究的意义（包括理论意义和现实意义，这个部分也可以合并归入“课题提出的背景”部分）；第二个问题“这项课题是怎样进行研究的？”3.文献综述；4．课题研究的理论依据；5．课题研究的目标；6．课题研究的主要内容；7．课题研究的对象；8．课题研究的方法；9. 课题研究的主要过程（研究的步骤）； 除了第9部分外，从第1到第8部分在填报课题立项申报表、在制定课题研究方案、在开题报告中，都有要求，内容基本相同。到了撰写结题报告时，只须稍作适当修改就可以了。而第9部分，则需要通过对
内容概要：本文档重点讲述了网络安全应急响应的各项准备工作，涵盖了‘1+X’网络安全应急响应的职业技能等级证书概述、应急响应的基础知识、应急响应组织的建立、风险评估与改进、应急响应预案的制定以及详细的应急响应计划处置样例。文中详细介绍了各级职业技能的要求和任务，尤其关注如何未雨绸缪，制定完善的应急预案以应对潜在的网络安全风险；同时也探讨了如何在网络安全事件发生时，采取及时有效的应急处置措施。 适合人群：从事或有兴趣进入网络安全领域的从业人员，尤其是准备考取‘1+X’网络安全应急响应职业技能等级证书的相关人员。 使用场景及目标：帮助读者了解网络安全应急响应的基本概念及其在整个国家安全框架中的重要地位；指导读者学会如何建立健全高效的应急响应组织结构，如何进行全面的风险评估以及如何编制切实可行的应急预案；通过实例剖析，增强读者应对突发网络安全事件的能力。文档的目标在于提升读者在不同层面的专业技能，包括但不限于系统备份、日志分析、安全漏洞修复等方面的能力。 阅读建议：此文档结构清晰，内容详尽，非常适合有一定基础的技术从业者参考学习。建议读者逐章节深入了解，特别是关注自身岗位对应的技能细分类别。此外，结合实例深入理解和练习如何进行应急处置是非常有价值的，有助于提升自身的实战能力。