「java探针跟踪」java跟踪调试
本篇文章给大家谈谈java探针跟踪，以及java跟踪调试对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
如何使用Diagnostics工具监控应用服务器
1 文档编写目的
本文档介绍HP Diagnostics应用服务器监控工具的安装、配置、作用以及影响。
2 HP Diagnostics组件介绍
2.1Diagnostics Probe
Diagnostics Probe(探针)负责从应用程序中捕捉各种事件、对象，计算度量信息并将结果发送到Diagnostics Server。Java Probe还提供剖析功能，能获取到与被测程序有关的更细节的诊断信息。
2.2Diagnostics Servers
Diagnostics Servers负责协调Probe及其他HP软件，处理从各个组件搜集的性能诊断数据，并以各种视图的形式展示出来。
Mediator模式的Diagnostics Server接受来自Probe的诊断数据，并通过进一步处理和计算，生成可供在视图上展示的数据。
Commander模式的Diagnostics Server负责调控Diagnostics各个组件及其他外部产品（LoadRunner Controller、Performance Center等），跟踪各个组件的工作状态。Commander模式的另一个作用是为最终用户提供一个监控各种性能视图，执行各种参数配置的界面。同时Commander模式的Diagnostics Server也拥有Mediator模式的Server的数据处理功能。
2.3Diagnostics结构图
l 一套Diagnostics系统中包括至少一个Command模式下的Server，可以包含0-N个Mediator模式的Server
3 HP Diagnostics安装及配置
3.1HP Diagnostics 系统硬件配置要求
3.1.1Diagnostics Server
Platform
Item
Up to 10 Probes
Up to 20 Probes
Up to 10 Probes
Windows
CPU
1X1.0GHZ
1X2.0GHZ
2X2.4GHZ
Windows
Memory
768MB
1GB
3GB
Solaris
CPU
1XUltra Sparc 2
2XUltra Sparc 2
2XUltra Sparc 3
Solaris
Memory
1GB
1.5GB
3GB
Linux
CPU
1X1.0GHZ
1X2.0GHZ
2X2.4GHZ
Linux
Memory
768MB
1GB
3GB
HP-UX
CPU
1X1.0GHZ
1X2.0GHZ
2X2.4GHZ
HP-UX
Memory
768MB
1GB
3GB
All
Java Heap
350MB
700MB
1400MB
All
Disk
3 GB per probe
3.1.2Diagnostics JAVA Probe
Platform
All Platforms
Memory
50 MB Additional RAM
Free Hard Disk Space
200 MB Additional Space
3.2HP Diagnostics 系统安装
3.2.1Diagnostics Server安装
在Windows系统下安装Diagnostics Server的步骤如下：
l 从安装文件所在文件夹中运行DiagnosticsServerSetupWin_8_00.exe
l 阅读许可文档
l 选择安装路径
l 选择Server运行在Commander模式或Mediator模式下
l （如果选择了安装Commander模式的Server）选择时间同步方式，用于同步一套Diagnostics系统，这里选择Synchronize with system time。
l 选择Diagnostics Server是否与HP其他软件产品一起工作，没有的话直接选择Next
l 确认安装选项，开始安装
l 结束安装
3.2.2Windows下Diagnostics JAVA Probe安装
在Windows系统下安装Diagnostics JAVA Probe的步骤如下：
l 从安装文件所在文件夹中运行JavaAgentSetup_win_8_00.exe。
l 阅读许可文档。
l 选择安装目录。
l 确认安装选项，开始安装。
l 结束安装，自动弹出Agent配置界面。
选择如上图所示，点击“下一步”。
l 填写探针名称和组名称，以便在服务器端识别，组名称使用Default也可，点击“下一步”。
l 填写Diagnostics Server的IP地址及端口号，点击“下一步”。
l 配置后选项，勾选“运行JRE Instrumenter…”
l 添加JVM,选择复制参数。
l 将复制的参数添加到WebLogic启动文件中，重新启动WebLogic服务器。
3.2.3UNIX下Diagnostics JAVA Probe 安装
Diagnostics Java Probe在IBM AIX、HP UNIX以及Linux操作系统中安装方法一致。唯一的区别是不同的平台有不同的安装文件。例如：AIX平台的安装文件为JavaAgentSetup_ibm_8_00.bin、HP平台的安装文件为JavaAgentSetup_hp11x_8_00.bin。
下面以AIX平台root用户安装Java Probe为例进行说明：
一、以二进制方式上传安装文件至服务器。
二、执行 #chmod 755 JavaAgentSetup_ibm_8_00.bin授予文件可执行权限。
三、执行 #./ JavaAgentSetup_ibm_8_00.bin -console，根据提示进行安装即可，注意设置Java Probe的安装目录，此处假设为 /MercuryDiagnostics。
四、修改/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/etc下的三个配置文件配置Java Probe：
1、 dynamic.properties修改配置如下：
mediator.host.name=IP (diagnostics8服务器IP地址)
mediator.port.number=2612 (代理端与服务器的通信端口，默认2612)
2、 dispatcher.properties修改配置如下：
registrar.url=
(diagnostics8服务器IP地址和端口)
3、 probe.properties修改配置如下：
active.products=Enterprise
id=lcam
group=szcomtop
五、进入/opt/MercuryDiagnostics/JavaAgent/DiagnosticsAgent/bin，运行如下命令：
#./jreinstrumenter.sh –i /usr/java5(应用所使用的JVM的安装路径)
生成一段代码。
六、将生成的代码添加到WebLogic启动文件中，重新启动WebLogic服务器。
4 HP Diagnostics 基本功能
打开IE浏览器输入;diagnostics_server_host:2006，可打开Diagnostics Server使用界面如下：
点击Open Diagnostics，输入用户名密码（均为admin）进入监控主界面
在此界面中选择对应的应用程序，可打开该应用程序的各种监控视图
Diagnositcs系统组织结构定义：
l Diagnostics System可包含多个Application，通过Diagnostics Server（Commander）的监控界面可以查看所有被监控的Application状态
l Application被监控程序，一个Application中可以包含多个Probe Groop
l Probe Group Probe组，可以是一组职能相近的Probe的集合
l Probe一个探针
4.1Server Summary View
l 最上方的Status视图列出Probe Group中的所有Probe，选择任意一个Probe就会列出该Probe的一些系统级的诊断信息。
l 左下方的All Aggregate Requests视图显示近5分钟内延迟最严重的Top 5请求（注意这个Top5是针对所有Probe侦测的所有请求而言的，如果需要观察某个Probe的Top5延迟请求，需要使用Filter）
l 右下方的Alert Events显示最近5个发声的Alert Notification（可以针对Server、Host、Probe Group、Probe设置各种Alert Notification Rule，当系统状况打到某个条件时发送Notification）
4.2Application Metric View
l 该视图显示过去5分钟内CPU使用率最高的5个Application
l 鼠标移动到某一条趋势线会有详细信息列出，见下图（这里的Latency延迟我不是太理解是指哪个对象的延迟，应该是指请求在应用程序的延迟）
4.3Dependent Services View
l 该视图显示延迟最严重的5个Dependent Services
l Dependent Services应该是指JDBC、RMI、WebServices、ADO（.NET）等非应用层的外部服务单元
l 上面是每个Dependent Services 的 Services Call View，显示针对这个Services的Top 5延迟的Services Call
4.4Host View
l 显示CPU使用率最高的5台服务器
4.5Load View
l 该视图显示Load值最高的前5个Layer
l Load值计算方法：
Load = Average Latency / Point Duration
其实Average Latency是指所有线程在当前Layer中的平均执行时间，Point Duration是一个合计的粒度值。
4.6Outbound Calls View
l 该视图显示延迟最高的5个Outbound Calls
l Diagnostic监控的Outbound Calls类型包括：
Ø Web Service
Ø RMI. Calls between Java servers.
Ø RFC (SAP R/3). Calls between SAP servers.
Ø CICS. Calls within an IBM environment.
Ø JMS. Calls between Java servers and message servers.
4.7Probe View
l 该视图显示JVM使用率最高的5个Probe信息。
l 视图对象表格
l 双击某个Probe会显示该Probe的Server Request View。
4.8SQL Statements View
l 该视图显示执行时间最长的5条SQL语句
l 默认是从所有Probe Group中的所有Probe上执行过的所有SQL语句中筛选，如果需要查看某个Probe的SQL执行情况，请使用Filter
l SQL语句的执行时间需超过设置的限定值才会在本视图中显示，限定值在相关配置文件中设置，默认限定值为1s。
l Details中列出所选SQL语句的执行位置、执行方法、次数、超时率等信息
4.9Aggregate Requests and Server Requests View
Aggregate Requests View
Server Requests View
l 显示响应时间最长的5个Aggregate Request和Server Request
l Aggregate Request和Server Request的区别，Aggregate Request的响应时间包括server requests和 dependent service calls的时间。
l Server Request的视图对象表的细节
显示请求的类型、请求发起的源码位置（Package、Method等）
l 在Server Request视图中，当选择了某个Server Request，视图中将会高亮该Request的趋势线，同时会
点击途中的、、图标，将会显示当前Request的Instance Tree（CallProfile）视图，其中各图标的含义如下：
A maximum instance tree，响应时间最长时的内部调用轨迹
A median instance tree，响应时间中等时的内部调用轨迹
A minimum instance tree，响应时间最短时的内部调用轨迹
典型的Instance Tree视图如下：
4.10 Status Views
l 显示系统中所有Probe Group、Probe、Host的概要信息及当前状态
4.11 Topology View
l 根据发送的请求的执行路径，获取并显示当前应用的网络拓扑图。
4.12 Transactions View
l 该视图显示响应时间最长的5个事务。
4.13 Trended Methods View
l 显示执行时间最长的5个方法，要对特定类、方法进行监测，需修改相关配置文件。
4.14 Layers View
l 该视图显示执行时间所占比重最高的5个Layer的延迟时间
l 视图对象表格细节
4.15 Call Profile View
l Call Profile Graph显示一个Server Request的方法调用过程，高亮最耗时的方法调用步骤
l Call Tree Table以制表的形式列出Call Profile Graph的调用过程，包括每个层级中各个方法调用的耗时、占比、使用的CPU时间等
l Details Pane显示某个方法调用的一些详细信息
4.16 Collections and Resources Views
Collections Views
l 该视图可以按照Collection Size或者growth排列显示出排名前5的Collection信息
Resources Views
l 该视图显示element数量前5位的Resource，Resource是指各种jar包
5 Diagnostics分析功能
访问J2EE Diagnostics Profiler的URL：
;probe_host:probeport/profiler 其中probeport默认为35000
工具栏的几个按钮：
l Refresh实时刷新最新数据
l Garbage Collection 强制垃圾回收
l Reset 重置计数和时间信息
l Link to Product information
l Help 打开On-line help
5.1使用Summary Tab来分析性能
l Summary Tab显示当前Probe的JVM内存使用情况、Load值和最慢的Requests
l 在Memory视图点击“drill into”按钮会显示堆的细分内容（详细请见Collection Tab章节）
l 在Load视图中会根据不同的层显示每个层的Load值，见下图：
l 在Slowest Requests视图中点击每个Request，会弹出对应的Call Profile View
5.2使用Hotspots Tab来分析性能
l Hotspots Tab显示耗时最长的方法、CPU时间使用最久的方法及执行时间最长的SQL语句
l 点击“view all methods”将链接到All Methods Tab，点击“view all SQL”将链接到All SQL Tab
l 在Slowest Methods和CPU Hotspots两个视图中点击某个方法，都会跳转到该方法的Call Profile 视图
l 在Slowest SQL视图中点击某个SQL语句，会显示完整版的SQL语句
5.3使用Metrics Tab来分析性能
5.4使用Threads Tab来分析性能
5.5使用All Methods Tab来分析性能
l 显示方法名、总耗时、平均耗时、被调次数、异常数、总CPU时间、平均CPU时间、所属层级
l 双击方法会显示该方法的Call Profile View
5.6使用All SQL Tab来分析性能
l 所有SQL的执行情况
5.7使用Exceptions Tab来分析性能
l 所有异常情况及次数
5.8使用Server Requests Tab来分析性能
l 所有Server Requests的统计信息。
5.9使用Web Services Tab来分析性能
l 现在最慢的前四个Web Service Operations（Inbound Call）和Outbound Web Service Calls
6 Diagnostics监控工具安装后风险分析
Ø 安装Diagnostics Server需要更改计算机MAC地址，要确保该机器允许修改MAC地址。
Ø Diagnostics Server与应用服务器是两台机器，安装Diagnostics Server不影响应用系统。
Ø Diagnostics服务器通过应用服务器上的Diagnostics Probe(探针)获取通过应用服务器的信息，进行监控。探针对服务器的影响微小，可忽略不计。
Ø 探针如果出现问题，导致weblogic服务无法启动，紧急情况可将添加在startWebLogic.sh文件中的那段代码去掉即可。
转载，仅供参考，祝你愉快，满意请采纳。1 文档编写目的
本文档介绍HP Diagnostics应用服务器监控工具的安装、配置、作用以及影响。
2 HP Diagnostics组件介绍
2.1Diagnostics Probe
Diagnostics Probe(探针)负责从应用程序中捕捉各种事件、对象，计算度量信息并将结果发送到Diagnostics Server。Java Probe还提供剖析功能，能获取到与被测程序有关的更细节的诊断信息。
2.2Diagnostics Servers
Diagnostics Servers负责协调Probe及其他HP软件，处理从各个组件搜集的性能诊断数据，并以各种视图的形式展示出来。
Mediator模式的Diagnostics Server接受来自Probe的诊断数据，并通过进一步处理和计算，生成可供在视图上展示的数据。
Commander模式的Diagnostics Server负责调控Diagnostics各个组件及其他外部产品（LoadRunner Controller、Performance Center等），跟踪各个组件的工作状态。Commander模式的另一个作用是为最终用户提供一个监控各种性能视图，执行各种参数配置的界面。同时Commander模式的Diagnostics Server也拥有Mediator模式的Server的数据处理功能。
linux安装全链路追踪工具skywalking8.0
SkyWalking是一个针对分布式系统的APM（应用性能监控）系统，特别针对微服务、cloud native和容器化架构，其核心是个分布式追踪系统。它通过探针自动收集所需的指标，且基于探针技术对应用零侵入零耦合。通过这些调用链路以及指标，SkyWalking APM会感知应用间关系和服务间关系，并进行相应的指标统计。
解压后，进入目录，默认自带了agent，这个是用来追踪java项目的。我因为是用来追踪php项目，所以这个用不上，如果要追踪php项目，需要另外安装php的agent，请查看我另外一篇文章( linux安装sky-php-agent )
bin里面是启动文件
config目录里面是配置文件
webapp目录里面是UI界面项目文件和配置文件
默认情况下，只需要更改一下 config/application.yml文件
默认的restHost和gRPCHost的IP为0.0.0.0，我这里改成我这边内网的IP。这里要注意一下，一旦改了IP，就只能用这个IP，比如我这里改成了内网IP，那么用127.0.0.1都不能访问。
如果需要更改UI界面访问的端口，可以修改 webapp/webapp.yml，里面配置文件很简单
注意一下，如果要想能够让受控端访问到skywalking服务，那么必须将12800端口对受控端服务器打开。WEB界面的端口，我这里是8081，大家可以改成自己需要的端口。
变更完配置后，就可以进去bin目录下，运行 startup.sh ，服务就会启动。然后通过http://服务器ip:8081进行界面访问。
受控端如果也启动了的话，这个时候，界面里就自动会出现数据了。
emmmm.....这里有个坑，默认情况下，打开界面什么数据都看不到，这个需要点击右上角的“自动”按钮，让按钮变成蓝色，这个时候就会有数据出现了。
如果还是没有出现数据，那就检查受控端服务是不是已经启动了，或者去看一下logs目录下的日志。如果受控端连接服务端出现错误，就看skywalking-oap-server.log；如果受控端一切正常，界面数据还是不显示，就看webapp.log
我在安装的时候，使用startup.sh启动文件，又遇到一个坑。这个启动文件，无论中间是不是有报错，都会提示启动成功。而且因为没有停止的命令，如果重复运行startup.sh，日志里会提示端口占用。这个时候，需要使用命令先查看占用端口的进程，然后杀掉进程，再重新运营启动文件才可以。
如何防止java中的内存泄漏
尽管java虚
拟机和垃圾回收机制治理着大部分的内存事务，但是在java软件中还是可能存在内存泄漏的情况。的确，在大型工程中，内存泄漏是一个普遍问题。避免内存泄
漏的第一步，就是要了解他们发生的原因。这篇文章就是要介绍一些常见的缺陷，然后提供一些非常好的实践例子来指导你写出没有内存泄漏的代码。一旦你的程序
存在内存泄漏，要查明代码中引起泄漏的原因是很困难的。同时这篇文章也要介绍一个新的工具来查找内存泄漏，然后指明发生的根本原因。这个工具轻易上手，可
以让你找到产品级系统中的内存泄漏。
垃圾回收（GC）的角色
虽然垃圾回收关心着大部分的
问题，包括内存治理，使得程序员的任务显得更加轻松，但是程序员还是可能犯些错误导致内存泄漏问题。GC(垃圾回收)通过递归对所有从“根”对象(堆栈中
的对象，静态数据成员，JNI句柄等等)继续下来的引用进行工作，然后标记所有可以访问的活动着的对象。而这些对象变成了程序唯一能够操纵的对象，其他的
对象都被释放了。因为GC使得程序不能够访问那些被释放的对象，所以这样做是安全的。
内存治理可以说是自动的，但是这并没有让程
序员脱离内存治理问题。比方说，对于内存的分配（还有释放）总是存在一定的开销，尽管这些开销对程序员来说是隐含的。一个程序假如创建了很多对象，那么它
就要比完成相同任务而创建了较少对象的程序执行的速度慢（假如其他的条件都相同）。
文章更多想说的，导致内存泄漏主要的原因是，
先前申请了内存空间而忘记了释放。假如程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器验证这些对象是否不再需
要。正如我们前面看到的，假如存在对象的引用，这个对象就被定义为“活动的”，同时不会被释放。要确定对象所占内存将被回收，程序员就要务必确认该对象不
再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。注重，当局部变量不需要时，不需明显的设为null，因为一个方法执行完
毕时，这些引用会自动被清理。
从更高一个层次看，这就是所有存在内存管的语言对内存泄漏所考虑的事情，剩余的对象引用将不再会被使用。
典型的泄漏
既然我们知道了在java中确实会存在内存泄漏，那么就让我们看一些典型的泄漏，并找出他们发生的原因。
全局集合
在大型应用程序中存在各种各样的全局数据仓库是很普遍的，比如一个JNDI-tree或者一个session table。在这些情况下，注重力就被放在了治理数据仓库的大小上。当然是有一些适当的机制可以将仓库中的无用数据移除。
可以有很多不同的解决形式，其中最常用的是一种周期运行的清除作业。这个作业会验证仓库中的数据然后清除一切不需要的数据。
另一个办法是计算引用的数量。集合负责跟踪集合中每个元素的引用者数量。这要求引用者通知集合什么时候已经对元素处理完毕。当引用者的数目为零时，就可以移除集合中的相关元素。
高速缓存
高速缓存是一种用来快速查找已经执行过的操作结果的数据结构。因此，假如一个操作执行很慢的话，你可以先把普通输入的数据放入高速缓存，然后过些时间再调用高速缓存中的数据。
高速缓存多少还有一点动态实现的意思，当数据操作完毕，又被送入高速缓存。一个典型的算法如下所示：
1． 检查结果是否在高速缓存中，存在则返回结果；
2． 假如结果不在，那么计算结果；
3． 将结果放入高速缓存，以备将来的操作调用。
这个算法的问题（或者说潜在的内存泄漏）在最后一步。假如操作是分别多次输入，那么存入高速缓存的内容将会非常大。很明显这个方法不可取。
为了避免这种潜在的致命错误设计，程序就必须确定高速缓存在他所使用的内存中有一个上界。因此，更好的算法是：
1． 检查结果是否在高速缓存中，存在则返回结果；
2． 假如结果不在，那么计算结果；
3． 假如高速缓存所占空间过大，移除缓存中旧的结果；
4． 将结果放入高速缓存，以备将来的操作调用。
通过不断的从缓存中移除旧的结果，我们可以假设，将来，最新输入的数据可能被重用的几率要远远大于旧的结果。这通常是一个不错的设想。
这个新的算法会确保高速缓存的容量在预先确定的范围内。精确的范围是很难计算的，因为缓存中的对象存在引用时将继续有效。正确的划分高速缓存的大小是一个复杂的任务，你必须权衡可使用内存大小和数据快速存取之间的矛盾。
另一个解决这个问题的途径是使用java.lang.ref.SoftReference类来将对象放入高速缓存。这个方法可以保证当虚拟机用完内存或者需要更多堆的时候，可以释放这些对象的引用。
类装载器
Java类装载器创建就存在很多导致内存泄漏的漏洞。由于类装载器的复杂结构，使得很难得到内存泄漏的透视图。这些困难不仅仅是由于类装载器只与“普通
的”对象引用有关，同时也和对象内部的引用有关，比如数据变量，方法和各种类。这意味着只要存在对数据变量，方法，各种类和对象的类装载器，那么类装载器
将驻留在JVM中。既然类装载器可以同很多的类关联，同时也可以和静态数据变量关联，那么相当多的内存就可能发生泄漏。
定位内存泄漏
经常地，程序内存泄漏的最初迹象发生在出错之后，在你的程序中得到一个OutOfMemoryError。这种典型的情况发生在产品环境中，而在那里，
你希望内存泄漏尽可能的少，调试的可能性也达到最小。也许你的测试环境和产品的系统环境不尽相同，导致泄露的只会在产品中暴露。这种情况下，你需要一个低
负荷的工具来监听和寻找内存泄漏。同时，你还需要把这个工具同你的系统联系起来，而不需要重新启动他或者机械化你的代码。也许更重要的是，当你做分析的时
候，你需要能够同工具分离而使得系统不会受到干扰。
一个OutOfMemoryError经常是内存泄漏的一个标志，有可能应用
程序的确用了太多的内存；这个时候，你既不能增加JVM的堆的数量，也不能改变你的程序而使得他减少内存使用。但是，在大多数情况下，一个
OutOfMemoryError是内存泄漏的标志。一个解决办法就是继续监听GC的活动，看看随时间的流逝，内存使用量是否会增加，假如有，程序中一定
存在内存泄漏。
具体输出
有很多办法来监听垃圾回收器的活动。也许运用最广泛的就是以：-Xverbose:gc选项运行JVM，然后观察输出结果一段时间。
[memory] 10.109-10.235: GC 65536K-16788K (65536K), 126.000 ms
箭头后的值（在这个例子中 16788K）是垃圾回收后堆的使用量。
控制台
观察这些无尽的GC具体统计输出是一件非常单调乏味的事情。好在有一些工具来代替我们做这些事情。The JRockit Management Console可以用图形的方式输出堆的使用量。通过观察图像，我们可以很方便的观察堆的使用量是否伴随时间增长。
Figure 1. The JRockit Management Console
治理控制台甚至可以配置成在堆使用量出现问题（或者其他的事件发生）时向你发送邮件。这个显然使得监控内存泄漏更加轻易。
内存泄漏探测工具
有很多专门的内存泄漏探测工具。其中The JRockit Memory Leak
Detector可以供来观察内存泄漏也可以针对性地找到泄漏的原因。这个强大的工具被紧密地集成在JRockit
JVM中，可以提供最低可能的内存事务也可以轻松的访问虚拟机的堆。
专门工具的优势
一旦
你知道程序中存在内存泄漏，你需要更专业的工具来查明为什么这里会有泄漏。而JVM是不可能告诉你的。现在有很多工具可以利用了。这些工具本质上主要通过
两种方法来得到JVM的存储系统信息的：JVMTI和字节码仪器。Java虚拟机工具接口（JVMTI）和他的原有形式JVMPI（压型接口，PRofiling Interface）都是标准接口，作为外部工具同JVM进行通信，搜集JVM的信息。字节码仪器则是引用通过探针获得工具所需的字节信息的预处理技术。
通过这些技术来侦测内存泄漏存在两个缺点，而这使得他们在产品级环境中的运用不够理想。首先，根据两者对内存的使用量和内存事务性能的降级是不可以忽略
的。从JVM获得的堆的使用量信息需要在工具中导出，收集和处理。这意味着要分配内存。按照JVM的性能导出信息是需要开销的，垃圾回收器在搜集信息的时
候是运行的非常缓慢的。另一个缺点就是，这些工具所需要的信息是关系到JVM的。让工具在JVM开始运行的时候和它关联，而在分析的时候，分离工具而保持
JVM运行，这显然是不可能的。
既然JRockit Memory Leak
Detector是被集成到JVM中的，那么以上两种缺点就不再存在。首先，大部分的处理和分析都是在JVM中完成的，所以就不再需要传送或重建任何数
据。处理也可以建立在垃圾回收器的基础上，即提高速度。再有，内存泄漏侦测器可以同一个运行的JVM关联和分离，只要JVM在开始的时候伴随着
–Xmanagement选项（通过远程JMX接口答应监听和治理JVM）。当工具分离以后，工具不会遗留任何东西在JVM中；JVM就可以全速运行代码
就似乎工具关联之前一样。
java探针跟踪的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java跟踪调试、java探针跟踪的信息别忘了在本站进行查找喔。