最近正在进行从Spring Boot往Spring Cloud上改造升级。之前部署的应用程序比较少，还没什么问题。当Spring Cloud项目逐步新增之后，问题就爆发了，服务器内存不够用了。而现有的用户体量也没必要对服务器再次进行升级，于是就开始着手Spring Boot启动时JVM内存配置的优化。
公司众多系统中有一个系统使用的是 CMS 垃圾回收器，JVM 初始堆内存不等于最大堆内存，但通过监控信息发现：在经过一次 FullGC 之后，服务器物理内存剩余空间并未提升，运维同事告诉我说，有内存泄露，因为 GC 了之后，内存并没有被释放。按照大部分人的理解，FullGC 之后 JVM 进程会释放的内存一部分还给物理内存，下面通过几个实验来对比验证一下 CMS 和 G1 的物理内存归还机制。
1.参数的含义 -vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M -vmargs 说明后面是VM的参数，所以后面的其实都是JVM的参数了 -Xms128m JVM初始分配的堆内存 -Xmx512m JVM最大允许分配的堆内存，按需分配 -XX:PermSize=64M JVM初始分配的非堆内存 -XX:MaxPermSize=128M JVM最大允许分配的非堆内存，按需分配
关于java的JVM这块儿知识，在项目做大之后，一些性能的优化，要涉及到数据库，一些缓存要放在内存中。还有一些JMS的消息传播等等，高大上的知识需要有JVM内存模型知识的支持。所以自问自答，来回答下面几个问题。
Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个Java虚拟机。Tomcat的内存溢出本质就是JVM内存溢出，所以在本文开始时，应该先对Java JVM有关内存方面的知识进行详细介绍。
本人所在公司有一个系统部署单个tomcat上，该系统由前开发人员开发。本人于两年前接手，在对该系统进行开发运维过程中，先后解决了两种tomcat宕机无法提供服务情况，具体如下：
如果我们所在公司的业务量比较大，在生产环境经常会出现JVM内存溢出的现象，那我们该如何快速响应，快速定位，快速恢复问题呢？
前提：某大型跨境电商业务发展非常快，线上机器扩容也很频繁，但是对于线上机器的运行情况，特别是jvm内存的情况，一直没有一个统一的标准来给到各个应用服务的owner。
在上一章节中，我们在一个节点上快速构建了一个ES集群，方便我们快速入门。但是实际生产应用中，我们都会根据公司实际的生产情况，比如公司业务日志的数据量、平台的数据访问量去选择我们服务器节点的配置。那么关于节点的配置这块，这里先不做过多讲解。腾云ES服务提供了各种场景下的套餐，用户可以非常方便的选择适合自己的产品。后续我将陆续给出我的建议。
使用 top 指令，服务器中 CPU 和 内存的使用情况，-H 可以按 CPU 使用率降序，-M 内存使用率降序。排除其他进程占用过高的硬件资源，对 Java 服务造成影响。
这里向大家描述一下如何使用Tomcat配置JVM参数，Tomcat本身不能直接在计算机上运行，需要依赖于硬件基础之上的操作系统和一个java虚拟机。您可以选择自己的需要选择不同的操作系统和对应的JDK的版本，但还是推荐您使用Sun公司发布的JDK。
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M 这里有几个问题： 1. 各个参数的含义什么？ 2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？ 3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？ 下面我们一一进行回答 1. 各个参数的含义什么？ 参数中-vmargs的意思是设置JVM参数
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M 这里有几个问题： 1. 各个参数的含义什么？ 2. 为什么有的机器我将-Xmx和-XX:MaxPermSize都设置为512M之后Eclipse可以启动，而有些机器无法启动？ 3. 为何将上面的参数写入到eclipse.ini文件Eclipse没有执行对应的设置？ 下面我们一一进行回答 1. 各个参数的含义什么？
打开 IDEA 安装目录，看到有一个 bin 目录，其中有两个 vmoptions 文件，需针对不同的JDK进行配置：
公司的业务量比较大，在生产环境如果经常出现OOM(Out Of Memory，JVM内存溢出)的现象，那该如何快速响应，快速定位，快速恢复问题呢？
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
永远不会有正当其时的时候，你总会觉得要么年纪太轻，要么太老，要么太忙，抑或是其他什么原因。如果你总是为找不到完美的时刻而困扰，那么，完美的时机永远不会出现。
如何在高性能服务器上进行JVM调优？ 为了充分利用高性能服务器的硬件资源，有两种JVM调优方案，它们都有各自的优缺点，需要根据具体的情况进行选择。 1. 采用64位操作系统，并为JVM分配大内存 我们知道，如果JVM中堆内存太小，那么就会频繁地发生垃圾回收，而垃圾回收都会伴随不同程度的程序停顿，因此，如果扩大堆内存的话可以减少垃圾回收的频率，从而避免程序的停顿。 因此，人们自然而然想到扩大内存容量。而32位操作系统理论上最大只支持4G内存，64位操作系统最大能支持128G内存，因此我们可以使用64位操作系
Jira和Confluence部署在同一台服务器上，跑一段时间后，发现访问jira和confluence时，打开越来越缓慢。这是因为根据主机物理内存不同，默认的java虚拟机内存也会不同（一个较低值），有时候不够用，可以修改JAVA默认的JVM内存设置，改善内存不足导致的问题。操作如下：
Zabbix自带监控系统的内存利用率和CPU利用率，但是系统内存并不能反应JVM内存情况
JVM中, 所有对象都是在堆中分配内存空间的,栈只用于保存局部变量和临时变量,如果是对象,只保存引用,实际内存还是在堆中;一个java对象占用的内存空间,除了一个固定大小的空间用于描述这个对象属于哪个类,其它的就用于保存它的字段的值;默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。设置jvm内存的方法，对于单独的.class，可以用下面的方法对Test运行时的jvm内存进行设置。
我们知道，java进程中的线程，是直接映射到服务的线程上，当创建的线程过多时，创建线程会失败，现象如下:
简单地说，ZooKeeper的连接与会话就是客户端通过实例化ZooKeeper对象来实现客户端与服务器创建并保持TCP连接的过程。本质上，Session就是一个TCP 长连接。
对于业务系统的性能优化，除了上面谈到的标准分析流程和分析要素外，再谈下其它一些性能问题引发的关键思考。
今天谈下业务系统性能问题分析诊断和性能优化方面的内容。这篇文章重点还是谈已经上线的业务系统后续出现性能问题后的问题诊断和优化重点。
我们首先来分析下如果一个业务系统上线前没有性能问题，而在上线后出现了比较严重的性能问题，那么实际上潜在的场景主要来自于以下几个方面。
java内存组成介绍：堆(Heap)和非堆(Non-heap)内存 按照官方的说法：“Java 虚拟机具有一个堆，堆是运行时数据区域，所有类实例和数组的内存均从此处分配。堆是在 Java 虚拟机启动时创建的。”“在JVM中堆之外的内存称为非堆内存(Non-heap memory)”。可以看出JVM主要管理两种类型的内存：堆和非堆。简单来说堆就是Java代码可及的内存，是留给开发人员使用的；非堆就是JVM留给 自己用的，所以方法区、JVM内部处理或优化所需的内存(如JIT编译后的代码缓存)、每个
一日凌晨，手机疯狂报警，短信以摧枯拉朽之势瞬间以百条的速度到达，我在睡梦中被惊醒，看到短信的部分内容如下：
研发工程师日常的工作除了开发实现新需求之外，排查定位问题也是重要的组成部分。如果在发生线上故障的时能够快速定位线上bug并且修复bug，不仅是研发工程师技术能力的重要体现，同时也可以帮助线上及时止血避免平台故障进一步蔓延，从而导致影响用户体验或者产生不可挽回的资损。但是实际上很多研发工程师由于工作经验还不充足，导致经常在遇到问题的时候不知所措，不知道该如何分析排查定位问题。因此本文主要聚焦日常工作中经常遇到的异常场景，梳理了问题排查定位的思路大图，这样大家在实际项目中如果遇到类似的异常场景，可以按照思路大图进行问题排查定位解决，相信大家掌握了故障定位的分析套路之后就可以做到遇到问题时临危不乱。
_NullPointer 出处：https://www.cnblogs.com/renwei/
前面提到了一个使用jstack的shell脚本，通过命令可以很快地定位到指定线程对应的堆栈信息。
JVM是Java Virtual Machine（Java虚拟机）的缩写，JVM是一种用于计算设备的规范，它是一个虚构出来的计算机，是通过在实际的计算机上仿真模拟各种计算机功能来实现的。 引入Java语言虚拟机后，Java语言在不同平台上运行时不需要重新编译。Java语言使用Java虚拟机屏蔽了与具体平台相关的信息，使得Java语言编译程序只需生成在Java虚拟机上运行的目标代码（字节码），就可以在多种平台上不加修改地运行。
Tomcat本身不能直接在计算机上运行，需要依赖于操作系统和一个Java虚拟机。JAVA程序启动时JVM会分配一个初始内存和最大内存给APP。当APP需要的内存超出内存的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃。
首先通过我们内部搭建的日志平台发现我们线上环境一个java应用有大量的http接口请求超时，登录linux服务器查看网络环境没有问题，判断是应用自身运行异常，重启应用后发现异常还在，开始查找问题。
前几天我们分享了我们java中的基石JVM的相关内存模型（要想精通java，你必须得知道java的内存模型，不忽悠）以及类加载机制（java类加载机制，再也不怕面试官的刁难），其实在我们平时开发中，大部分工程师在生产环境部署java的时候很少去思考这个JVM的相关参数到底怎么去设置，更很少去预估我们程序所需的内存以及并发量等等，或者是直接参考公司资深工程师写的配置。
1、CPU，如果存在大量的计算，他们会长时间不间断的占用CPU资源，导致其他资源无法争夺到CPU而响应缓慢，从而带来系统性能问题，例如频繁的FullGC，以及多线程造成的上下文频繁的切换，都会导致CPU繁忙，一般情况下CPU使用率<75%比较合适。 2、内存，Java内存一般是通过jvm内存进行分配的，主要是用jvm中堆内存来存储Java创建的对象。内存的读写速度非常快，但是内存空间又是有限的，当内存空间被占满，对象无法回收时，就会导致内存溢出或内存泄漏。 3、磁盘I/O，磁盘的存储空间要比内存存储空间大很多，但是磁盘的读写速度比内存慢，虽然现在引入SSD固态硬盘，但是还是无法跟内存速度相比。 4、网络，带宽的大小，会对传输数据有很大影响，当并发量增加时，网络很容易就会成为瓶颈。 5、异常，Java程序，抛出异常，要对异常进行捕获，这个过程要消耗性能，如果在高并发的情况下，持续进行异常处理，系统的性能会受影响。 6、数据库，数据库的操作一般涉及磁盘I/O的读写，大量的数据库读写操作，会导致磁盘I/O性能瓶颈，进而导致数据库操作延迟。 7、当在并发编程的时候，经常会用多线程操作同一个资源，这个时候为了保证数据的原子性，就要使用到锁，锁的使用会带来上下文切换，从而带来性能开销，在JDK1.6之后新增了偏向锁、自旋锁、轻量级锁、锁粗化、锁消除。
某些对象或者数据没有利用价值了，但是由于某些原因占用着内存，无法被回收，就造成了内存泄漏。
在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户， 这些突发的无法预先感知的热key都是系统潜在的巨大风险。
Druid进程可以以任意方式进行部署，为了方便部署，建议分为三种服务器类型：主服务器（Master）、查询服务器（Query）、数据服务器（Data）。
去年双十一腾讯云搞活动，198元购买了三年轻量级服务器的使用权，配置：4G内存，8G带宽，1200G月流量，80G硬盘，因此，我就闲来无事部署了属于我自己的个人网站；大概部署几个服务：Nginx、Redis、MySQL、jenkins、vue项目、博客网站等。
JVM 发生内部崩溃，那么必然会生成"hs_err_pid"开头的文件,下面讲一种常见情况:
很多人看了分布式唯一 ID 相关的文章，觉得都设计的非常复杂，大厂的分布式唯一ID生成方案为什么要设计的这么复杂？看完本篇文章，希望能够给你解惑！
版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
Memory Management 在整体应用架构中，非生产环境情况下，一般 1GB 或者 2GB 的 RAM 就足够了。如果我们将这个应用程序划分为 20 或 30 个独立的微服务，那么很难期望 RAM 仍将保持在 1GB 或 2GB 左右。特别是如果我们使用 Spring Cloud 的时候。 首先，准备三个服务，Eureka 服务 + 提供 REST API 的两个简单的微服务，并将微服务注册到 Eureka。此处，不以任何方式限制这些应用程序的内存使用。 提示：Spring Cloud 简单应用
最近在做一个项目，顺便把前段时间学习的ElasticSearch给用上，所以我在服务器上面安装了ES
所有的Java开发人员可能会遇到这样的困惑？我该为堆内存设置多大空间呢？OutOfMemoryError的异常到底涉及到运行时数据的哪块区域？该怎么解决呢？其实如果你经常解决服务器性能问题，那么这些问题就会变的非常常见，了解JVM内存也是为了服务器出现性能问题的时候可以快速的了解那块的内存区域出现问题，以便于快速的解决生产故障。
打出jstack文件，通过IBM Thread and Monitor Dump Analyzer for Java工具查看如下：
领取专属 10元无门槛券
手把手带您无忧上云
