（2）stack - 输出当前方法被调用的调用路径, 一个方法被执行的路径非常多，不知道这个方法是从那里被执行，就可以采用
Arthas 是一款线上监控诊断产品，通过全局视角实时查看应用 load、内存、gc、线程的状态信息，并能在不修改应用代码的情况下，对业务问题进行诊断，包括查看方法调用的出入参、异常，监测方法执行耗时，类加载信息等，大大提升线上问题排查效率。
一般 Unix 系统中，用户态的程序通过malloc()调用申请内存。如果返回值是 NULL， 说明此时操作系统没有空闲内存。这种情况下，用户程序可以选择直接退出并打印异常信息或尝试进行 GC 回收内存。然而 Linux 系统总会先满足用户程序malloc请求，并分配一片虚拟内存地址。只有在程序第一次touch到这片内存时，操作系统才会分配物理内存给进程。具体我们可以看下如下demo:
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
目前采用微服务架构已经逐渐成为企业架构的标准范式，而大多微服务是基于Spring Cloud框架来进行应用的构建的，所以在开发实践中，甚至生产环境中，会遇到java相关问题，例如系统运行变慢、内存OOM，堆栈异常等问题，这里结合我之前的一些实践提供一些相关工具，和大家一起分享我们的诊断思路和解决技巧。
执行tomcat ./shutdown.sh 后，虽然tomcat服务不能正常访问了，但是ps -ef | grep tomcat 后，发现tomcat对应的java进程未随web容器关闭而销毁，进而存在僵尸java进程。网上看了下导致僵尸进程的原因可能是有非守护线程（即User Thread）存在，jvm不会退出（当JVM中所有的线程都是守护线程的时候，JVM就可以退出了；如果还有一个或以上的非守护线程则JVM不会退出）。通过一下命令查看Tomcat进程是否结束：
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
概述 jps 命令类似与 linux 的 ps 命令，但是它只列出系统中所有的 Java 应用程序。 通过 jps 命令可以方便地查看 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息。
JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。
JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》)
前言 JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》) 内存泄露Bug现场 一个线上稳定运行了三年的系统，从物理机迁移到docker环境后，运行了一段时间，突然被监控系统发出了某些实例不可用的报警。所幸有负载均衡，
鉴于网上对于sdn开发相关的资料较少又乱的现状，从这篇文章开始，我将陆续分享我在sdn开发过程中的经验，我的sdn项目开发是基于opendaylight的release-lithium-sr3版本，该版本相对稳定。 继上篇文章《sdn开发环境的搭建（win7环境）- SDN开发笔记（一）》之后，我在Linux下使用odl控制器，在使用之前，先将使用环境搭建好，我使用的Linux是ubuntu 14.04桌面版，采用vmware虚拟机方式，具体为： Vmware版本：VMware-workstation-fu
之前写了JConsole、VisualVM 依赖的 JMX 技术，然后放出了一个用纯 JMX 实现的 web 版本的 JConsole 的截图，今天源码来了。
在实际的业务场景中，我们往往倾向于认为容器环境与虚拟机一样，可以完全自定义不同参数的虚拟 CPU 和虚拟 Memory 资源。其实，从本质上而言，容器更倾向于一种隔离机制环境，其中一个进程的资源（ CPU、内存、文件系统、网络等）与另一个进程隔离。这种隔离是可能的，因为 Linux 内核中有一个名为 CGroups 的特性。然而，一些从执行环境收集信息的应用程序在 CGroup 存在之前就已经实现了。像大多数常用的命令行 “top”、“free”、“ps” 等诸如此类的工具，甚至 JVM 都没有针对在容器内执行进行优化，毕竟，容器是一个高度受限的 Linux 进程。
该说不说！小编做的这些功能，最讨厌的就是优化！某些前辈大佬写的代码小辈我实在不敢恭维！那逻辑！那sql！
前言 JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存，同时对物理内存的使用做了定量的分析，从而实锤了Bug的源头。笔者将此Bug分析的过程写成博客，以飨读者。 由于物理内存定量分析部分用到了linux kernel虚拟内存管理的知识，读者如果有兴趣了解请看ulk3(《深入理解linux内核第三版》) 内存泄露Bug现场 一个线上稳定运行了三年的系统，从物理机迁移到docker环境后，运行了一段时间，突然被监控系统发出了某些实例不可用的报警。所幸有负载均衡，可
当我们将 JVM 生态中的关键要素，例如，垃圾收集器、堆大小和运行时编译器设置默认值时，许多技术人员（开发、运维人员）或许应该意识到在 Linux 容器生态中（诸如，Docker、Rkt、RunC、Lxcfs 等）内所运行的 Java 进程的实际行为与预期不符。当我们在没有任何调优参数（例如，最为简洁的的启动命令行：“ java -jar myapplication .jar”）的情况下执行 Java 应用程序时，JVM 将自行调整某些特定的参数，以在当前执行环境中获得最佳性能表现。
该命令主要与jmap搭配使用，用来分析jmap转储的转储快照。其中构建了一个微型的http/html服务器。生成dump文件的分析结果后可以通过浏览器进行查看。 通常情况下不采用jhat进行分析，一方面，分析工作需要耗费额外的资源和时间，既然都要在其他机器进行，则不需要限定于上述工具。另外一方面，jhat界面比较简陋，可以用visualVM，eclipse的Memory Analizer 等更加专业的分析工具进行替换。
jstat用法 其中-gc可以换成-class 、-gcnew、-gcold等参数；而54992表示的JVM的进程id（可能通过上面的jps命令查看） ;4s表求每4秒打印一次，后面的3表求共打印三次。 打印的各参数含义如下： 1：S0C、S1C、S0U、S1U：Survivor 0/1区容量（Capacity）和使用量（Used） 2：EC、EU：Eden区容量和使用量 3：OC、OU：年老代容量和使用量 4：MC、MU：元数据区容量和使用量 5：CCSC、CCSU：压缩类空间容量和使用量 5：YGC、YGT：年轻代GC次数和GC耗时 6：FGC、FGCT：Full GC次数和Full GC耗时 7：GCT：GC总耗时 jstat可以用来判断系统是否出现了内存泄漏，方法是通过一短长时间的观察OU的增长情况，如果OU稳定增长，则有可能出现内存泄漏。
内存问题，脑瓜疼脑瓜疼。脑瓜疼的意思，就是脑袋运算空间太小，撑的疼。本篇是《荒岛余生》系列第三篇，让人脑瓜疼的内存篇。其余参见：
jps位于jdk的bin目录下，其作用是显示当前系统的java进程情况，及其id号。 jps相当于Solaris进程工具ps。不象”pgrep java”或”ps -ef grep java”，jps并不使用应用程序名来查找JVM实例。因此，它查找所有的Java应用程序，包括即使没有使用java执行体的那种（例如，定制的启动 器）。另外，jps仅查找当前用户的Java进程，而不是当前系统中的所有进程。
随着系统自身数据量的增长，访问量增加，系统的响应通常会越来越慢，或者是新的功能在性能上无法满足修去，这个时候需要对系统进行性能调优。调优是一个复杂的过程，涉及的方面有：硬件，操作系统，运行环境软件和应用本身。
jps是java提供的一个显示当前所有java进程pid的命令，适合在linux/unix平台上简单察看当前java进程的一些简单情况。
在高并发下，Java程序的GC问题属于很典型的一类问题，带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」，由于GC期间都存在Stop The World问题，因此很容易导致服务超时，引发性能问题。
CMS（标记-清除）——》G1（标记整理）——》ZGC（染色指针，多重映射等技术）
JVM大家可能都知道是个什么玩意-Java虚拟机，但是到底是个什么鬼？相信即使工作3-5年的程序员可能也不大了解。
列出java进程， -q 只输出进程id -m 输出Java进程（主函数）的参数 -l 可以用于输出主函数的完整路径 -v可以显示传递给JVM的参数
加上-H这个选项启动top，top一行显示一个线程（指的是（轻量级）进程？ ）。否则，它一行显示一个进程。
生产环境中直接排查 JVM 的话，最简单的做法就是使用 JDK 自带的 6 个非常实用的命令行工具来排查。它们分别是：jps、jstat、jinfo、jmap、jhat 和 jstack，它们都位于 JDK 的 bin 目录下，可以使用命令行工具直接运行，其目录如下图所示：
jdk在安装的时候会提供一些性能分析、故障诊断、JVM监控之类的工具，了解这些工具对我们分析JVM内存、JVM调优有一定的帮助，本篇文章来学习一下。
JVM大家可能都知道是个什么玩意-Java虚拟机，但是到底是个什么鬼？相信即使工作3-5年的程序员可能也不大了解。 如题所述，今天与大家分享的是如何分析JVM的线程堆栈以及如何从堆栈信息中找出问题。
ELK介绍 在平时的工作当中，需要一个日志分析系统来分析各种各样的告警信息，而ELK可以简单满足这个需求。
云原生这么多微服务，当然需要一个诊断利器来排查问题。 Arthas 是阿里开源的 Java 诊断工具，深受开发者喜爱。在线排查问题，无需重启；动态跟踪 Java 代码；实时监控 JVM 状态。Arthas 支持 JDK 6+，支持 Linux/Mac/Windows，采用命令行交互模式，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。
命令：java -version：查看JDK安装版本，命令执行后显示如下，说明本系统默认已经安装JDK1.8.0_242。
jmap -heap 1234 查看进程号为1234的Java程序的整个jvm内存状态
首先通过我们内部搭建的日志平台发现我们线上环境一个java应用有大量的http接口请求超时，登录linux服务器查看网络环境没有问题，判断是应用自身运行异常，重启应用后发现异常还在，开始查找问题。
网上看到一个很有意思的美团面试题：为什么线程崩溃崩溃不会导致 JVM 崩溃，这个问题我看了不少回答，但发现都没答到根上，所以决定答一答，相信大家看完肯定会有收获，本文分以下几节来探讨
日志记录是软件开发中的一个重要主题，特别是如果您需要分析生产环境中的错误和其他意外事件。实现日志记录通常很容易。但正如您可能经历过的那样，日志记录远比看起来复杂得多。这就是为什么你可以在博客上找到很多关于它的文章。
最近参加面试经常被面试官问到有没有遇到过线上人内存溢出（OOM）的问题？遇到过的化你是怎么定位是哪个线程下哪些对象占用你内存太多造成的？提出这个问题其实面试官就是用来考察你到底有没有JVM调优经验。如果你在工作中并没有JVM方面的经验，也没有仔细看过线上定位和OOM问题的文章，那么99.9%这道题你要凉凉！
前面几章内容我们学习了JVM的内存回收和JVM参数等系列,今天墨白给大家分享的是jmap的使用以及内存溢出分析等详情,话不多说,正文开始;
简单：只需配置好tomcat-users.xml、catalina.bat（开启远程JMX）就可以通过部署一个probe.war来管理该Tomcat下所有的项目。
JDK 提供了一系列用于监控、诊断 Java 进程的工具，它们在 JDK 安装目录的 bin 目录下，有 jps、jcmd、jstack、jinfo、jmap 等。其中jmc、jconsole、jvisualvm 是 GUI 工具，其他大部分都是命令行工具。
根据man配置的信息可以得出pthread_create会创建一个线程，这个函数是linux系统的函数，可以用C或者C++直接调用，上面信息也告诉程序员这个函数在pthread.h， 这个函数有四个参数
这些问题在日常开发中可能被很多人忽视（比如有的人遇到上面的问题只是重启服务器或者调大内存，而不会深究问题根源），但能够理解并解决这些问题是Java程序员进阶的必备要求。本文将对一些常用的JVM性能调优监控工具进行介绍，希望能起抛砖引玉之用。本文参考了网上很多资料，难以一一列举，在此对这些资料的作者表示感谢！关于JVM性能调优相关的资料，请参考文末。
前面介绍了JVM相关的内存和线程相关的技术。对于JVM也算有了一个比较系统、完整的理论基础。理论总是作为指导实践的工具，但是从理论到实践，总会遇到一些虚拟机相关问题，故障。所以还需要学习一些常用的JVM排障工具，和一些常见的调优手段。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
