回答来自于问答智囊团成员：邓愉悦 专栏：https://cloud.tencent.com/developer/user/6835587 原因分析 1、tsf-agent 版本过低。 使用 JVM 监控功能时，实例的 tsf-agent 需为 1.21.0 或以上版本。如果 agent 版本过低，JVM 监控功能无法使用您需要对 agent 进行升级。 2、GC 日志配置被覆盖。 JVM 日志的采集依赖于 TSF 的 GC 日志配置。如果您自定义了 GC 日志配置，将会覆盖 TSF 的 GC 日志配置，这将导致无法在界面中查看 JVM 日志。 解决方案 1、JVM 如何升级 tsf-agent？ 首先我们需要对tsf-agent进行升级操作： VM 场景：您需要把实例移出集群后，再重新移入集群，重新部署服务实例。 容器场景：您需重新编写 dockerfile，生成新的镜像后重新部署服务实例。 这里我们先介绍下如何制作容器镜像。 Spring Cloud 应用构建材料： 我们需要在 Dockerfile 中增加 JVM 监控组件TencentCloudJvmMonitor然后在 CMD 命令中启动该组件。 注意：将 Spring Cloud 应用 JAR 包和 JVM 监控组件放在同级目录下，并在该目录下编写 Dockerfile。 FROM centos:7 RUN echo "ip_resolve=4" >> /etc/yum.conf RUN yum update -y && yum install -y java-1.8.0-openjdk # 设置时区。这对于日志、调用链等功能能否在 TSF 控制台被检索到非常重要。 RUN /bin/cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime RUN echo "Asia/Shanghai" > /etc/timezone ENV workdir /app/ # 下面的 jar 包可替换为您的 Spring Cloud 应用 jar 包，注意这个 jar 包要和您的 dockerfile 位于同一级目录 ENV jar provider-demo-0.0.1-SNAPSHOT.jar COPY ${jar} ${workdir} WORKDIR ${workdir} # JVM 监控组件要和您的 Dockerfile 位于同一级目录，并创建 JVM 监控数据采集目录 ENV agentjar TencentCloudJvmMonitor-1.0-RELEASE.jar COPY ${agentjar} ${workdir} RUN mkdir -p /data/tsf_apm/monitor/jvm-metrics/ # JAVA_OPTS 环境变量的值为部署组的 JVM 启动参数，在运行时 bash 替换。使用 exec 以使 Java 程序可以接收 SIGTERM 信号。 # 使用 JVM监控功能需要加上 gclog 和 javaagent 的配置, 否则将无法提供 jvm 监控能力 CMD ["sh", "-ec", "exec java -Xloggc:/data/tsf_apm/monitor/jvm-metrics/gclog.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails -verbose:gc -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=8 -XX:GCLogFileSize=50M -javaagent:${workdir}/${agentjar}=hascontroller=true ${JAVA_OPTS} -jar ${jar}"] 这里我们需要注意的是： JVM 监控功能依赖 javaagent，jdk1.5 以后才引入了 javaagent 技术，所以您需使用 jdk1.6 及以上版本，建议您使用 jdk1.8。 2、火焰图采集失败如何处理？ 火焰图适用于在 CPU 利用率持续较高的情况下进行热点函数分析。 在如下场景下，火焰图采集可能失败： 数据量过大：目前火焰图的数据量上限为2MB，超出时会采集失败；此时，请缩短所选择的采集时间后，重新进行采集。 当前无热点函数：进程处于低 CPU 消耗状态，即当前无热点函数时，火焰图采集可能失败（无法采集到热点函数）；此时，可尝试延长采集时间后重新采集，或待服务请求量较大时再重新采集。 无法和进程建立连接：发生无法和实例连接等异常情况时，采集任务会执行超时；此时，请您检查实例的连接状态，确认状态正常后再重新采集。 3、为何无法查看 JVM 日志？ JVM 日志的采集依赖于 TSF 的 GC 日志配置。如果自定义了 GC 日志配置，将会覆盖 TSF 的 GC 日志配置，这将导致无法在界面中查看 JVM 日志。 以上就是解决在使用TSF遇到JVM相关监控无法看到、以及JVM日志无法查看相关问题的一些解决办法，供大家参考下。

1) 方法区： a. 有时候也成为永久代，在该区内很少发生垃圾回收，但是并不代表不发生GC，在这里进行的GC主要是对方法区里的常量池和对类型的卸载 b. 方法区主要用来存储已被虚拟机加载的类的信息、常量、静态变量和即时编译器编译后的代码等数据。 c. 该区域是被线程共享的。 d. 方法区里有一个运行时常量池，用于存放静态编译产生的字面量和符号引用。该常量池具有动态性，也就是说 常量并不一定是编译时确定，运行时生成的常量也会存在这个常量池中。 2) 虚拟机栈: a. 虚拟机栈也就是我们平常所称的栈内存,它为java方法服务，每个方法在执行的时候都会创建一个栈帧，用于存储局部变量表、操作数栈、动态链接和方法出口等信息。 b. 虚拟机栈是线程私有的，它的生命周期与线程相同。 c. 局部变量表里存储的是基本数据类型、returnAddress类型（指向一条字节码指令的地址）和对象引用，这个对象引用有可能是指向对象起始地址的一个指针，也有可能是代表对象的句柄或者与对象相关联的位置。局部变量所需的内存空间在编译器间确定 d. 操作数栈的作用主要用来存储运算结果以及运算的操作数，它不同于局部变量表通过索引来访问，而是压栈和出栈的方式 e. 每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，持有这个引用是为了支持方法调用过程中的 动态连接.动态链接就是将常量池中的符号引用在运行期转化为直接引用。 3) 本地方法栈： 本地方法栈和虚拟机栈类似，只不过本地方法栈为Native方法服务。 4) 堆： java堆是所有线程所共享的一块内存，在虚拟机启动时创建，几乎所有的对象实例都在这里创建，因此该区域经常发生垃圾回收操作。 5) 程序计数器： 内存空间小，字节码解释器工作时通过改变这个计数值可以选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理和线程恢复等功能都需要依赖这个计数器完成。该内存区域是唯一一个java虚拟机规范没有规定任何OOM情况的区域。 image.png

可以前往作者专栏处留言提问喔

运行java -version 显示正确就行