前面提到了虚拟内存需要映射物理内存才能使用，这个映射关系被保存在内存中的页表（Page Table）。现代 CPU 架构中一般有 TLB （Translation Lookaside Buffer，翻译后备缓冲，也称为页表寄存器缓冲）存在，在里面保存了经常使用的页表映射项。TLB 的大小有限，一般 TLB 如果只能容纳小于 100 个页表映射项。 我们能让程序的虚拟内存对应的页表映射项都处于 TLB 中，那么能大大提升程序性能，这就要尽量减少页表映射项的个数：页表项个数 = 程序所需内存大小 / 页大小。我们要么缩小程序所需内存，要么增大页大小。我们一般会考虑增加页大小，这就大页分配的由来，JVM 对于堆内存分配也支持大页分配，用于优化大堆内存的分配。那么 Linux 环境中有哪些大页分配的方式呢？
Linux 内存管理模型不是咱们这个系列的讨论重点，我们这里只会简单提一些对于咱们这个系列需要了解到的，如果读者想要深入理解，建议大家查看 bin 神（公众号：bin 的技术小屋）的系列文章：一步一图带你深入理解 Linux 虚拟内存管理
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该
Java 19 中 Loom 终于 Preview 了，虚拟线程（VirtualThread）是我期待已久的特性，但是这里我们说的线程内存，并不是这种 虚拟线程，还是老的线程。其实新的虚拟线程，在线程内存结构上并没有啥变化，只是存储位置的变化，实际的负载线程（CarrierThread）还是老的线程。
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的;但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。同时，由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了要分析这个问题，理解JVM和操作系统之间的内存关系非常重要。接下来主要就Linux与JVM之间的内存关系进行一些分析。 一、Li
引言 在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约600m，Linux自身使用大约800m。从表面上，物理内存
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的；但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了？
一般 Unix 系统中，用户态的程序通过malloc()调用申请内存。如果返回值是 NULL， 说明此时操作系统没有空闲内存。这种情况下，用户程序可以选择直接退出并打印异常信息或尝试进行 GC 回收内存。然而 Linux 系统总会先满足用户程序malloc请求，并分配一片虚拟内存地址。只有在程序第一次touch到这片内存时，操作系统才会分配物理内存给进程。具体我们可以看下如下demo:
Java 凭借着自身活跃的开源社区和完善的生态优势，在过去的二十几年一直是最受欢迎的编程语言之一。步入云原生时代，蓬勃发展的云原生技术释放云计算红利，推动业务进行云原生化改造，加速企业数字化转型。
不同的 GC 堆大小动态伸缩有很大很大的差异（比如 ParallelGC 涉及 UseAdaptiveSizePolicy 启用的动态堆大小策略以及相关的 UsePSAdaptiveSurvivorSizePolicy、UseAdaptiveGenerationSizePolicyAtMinorCollection 等等等等的参数参与决定计算最新堆大小的方式以及时机），在这个系列以后的章节我们详细分析每个 GC 的时候再详细分析这些不同 GC 的动态伸缩策略。我们这里仅涉及大多数 GC 通用的堆大小伸缩涉及的参数：MinHeapFreeRatio 与 MaxHeapFreeRatio：
（2）stack - 输出当前方法被调用的调用路径, 一个方法被执行的路径非常多，不知道这个方法是从那里被执行，就可以采用
JVM本质就是一个进程，因此其内存空间（也称之为运行时数据区，注意与JMM的区别）也有进程的一般特点。深入浅出 Java 中 JVM 内存管理，这篇参考下。
java方面 java中的引用有几种? Java中的threadlocal是怎么用的? threadlocal中的内部实现是怎么样的? 哪种引用? java中的"final"关键字在多线程的语义中，有
OpenJDK 9中首次新增了一项实验性功能，JVM可借助该功能检测到自己运行在容器中，进而酌情调整内存限制。尽管过去几年来容器技术日渐流行，但包括JVM在内的很多工具依然需要通过宿主机的参数访问可用
在实际的业务场景中，我们往往倾向于认为容器环境与虚拟机一样，可以完全自定义不同参数的虚拟 CPU 和虚拟 Memory 资源。其实，从本质上而言，容器更倾向于一种隔离机制环境，其中一个进程的资源（ CPU、内存、文件系统、网络等）与另一个进程隔离。这种隔离是可能的，因为 Linux 内核中有一个名为 CGroups 的特性。然而，一些从执行环境收集信息的应用程序在 CGroup 存在之前就已经实现了。像大多数常用的命令行 “top”、“free”、“ps” 等诸如此类的工具，甚至 JVM 都没有针对在容器内执行进行优化，毕竟，容器是一个高度受限的 Linux 进程。
当我们将 JVM 生态中的关键要素，例如，垃圾收集器、堆大小和运行时编译器设置默认值时，许多技术人员（开发、运维人员）或许应该意识到在 Linux 容器生态中（诸如，Docker、Rkt、RunC、Lxcfs 等）内所运行的 Java 进程的实际行为与预期不符。当我们在没有任何调优参数（例如，最为简洁的的启动命令行：“ java -jar myapplication .jar”）的情况下执行 Java 应用程序时，JVM 将自行调整某些特定的参数，以在当前执行环境中获得最佳性能表现。
jps是java提供的一个显示当前所有java进程pid的命令，适合在linux/unix平台上简单察看当前java进程的一些简单情况。
概述 jps 命令类似与 linux 的 ps 命令，但是它只列出系统中所有的 Java 应用程序。 通过 jps 命令可以方便地查看 Java 进程的启动类、传入参数和 Java 虚拟机参数等信息。
前文我们没有提到，如何限制元空间的大小，其实就是限制 commit 的内存大小。元空间的限制不只是受限于我们的参数配置，并且前面我们提到了，元空间的内存回收也比较特殊，元空间的内存基本都是每个类加载器的 ClassLoaderData 申请并管理的，在类加载器被 GC 回收后，ClassLoaderData 管理的这些元空间也会被回收掉。所以，GC 是可能触发一部分元空间被回收了。所以元空间在设计的时候，还有一个动态限制 _capacity_until_GC，即触发 GC 的元空间占用大小。当要分配的空间导致元空间整体占用超过这个限制的时候，尝试触发 GC。这个动态限制也会在每次 GC 的时候动态扩大或者缩小。动态扩大以及缩小
该命令主要与jmap搭配使用，用来分析jmap转储的转储快照。其中构建了一个微型的http/html服务器。生成dump文件的分析结果后可以通过浏览器进行查看。 通常情况下不采用jhat进行分析，一方面，分析工作需要耗费额外的资源和时间，既然都要在其他机器进行，则不需要限定于上述工具。另外一方面，jhat界面比较简陋，可以用visualVM，eclipse的Memory Analizer 等更加专业的分析工具进行替换。
之前写了JConsole、VisualVM 依赖的 JMX 技术，然后放出了一个用纯 JMX 实现的 web 版本的 JConsole 的截图，今天源码来了。
今天，内网测试服务器A总是运行一段时间就服务器进程自行退出了，给出了“Java Result ：137”这样的错误码。上网查了一下这个137，感觉没有啥有价值的东西。一开始怀疑项目中的JNI调用崩溃到底层，但是没有看到core.*这样的崩溃日志，同时也没有发现OOM的日志，也没有常见的Java 的堆异常log，关键是同样的环境，另外一台机器B，压力远比这个大，都稳定运行很长时间没有问题。下午又崩溃了两三次，一度怀疑Java是不是有什么bug，不过这个想法立马被我否认了，先从自己找原因。
1、问题： 最近在往 HBase 写中文的时候，发现 hbase 查出来的数据会有部分中文乱码了，而部分中文又是正常的，按理来说，一般的乱码问题要么全乱，要么不乱。考虑到出现中文的地方都是来源于 hdfs 上的一个配置文件，而这个配置文件可以确定是 utf-8 编码的，那排除了原始文件导致的乱码，想想 MR 代码里也没有转码的逻辑，也排除了代码的问题，那就只有一种可能：Hadoop 集群的系统环境是异构的，这里面可能涉及到 linux 、java 的环境变量、配置的问题。 2、排查： （1）打印了整个集群的
-vmargs -Xms128M -Xmx512M -XX:PermSize=64M -XX:MaxPermSize=128M
分别复制tomcat目录下的 conf logs temp webapps work 这5个目录到 test1 和 test2下。
_NullPointer 出处：https://www.cnblogs.com/renwei/
应用程序出现OOM异常，你是否仍然通过看日志的方式去排查问题（该方式定位解决问题是大概率的巧合而已）？正确的排查方案是进行dump文件分析，你知道为什么吗？
不同的 GC 情况下，初始化以及扩展的流程可能在某些细节不太一样，但是，大体的思路都是：
jps位于jdk的bin目录下，其作用是显示当前系统的java进程情况，及其id号。 jps相当于Solaris进程工具ps。不象”pgrep java”或”ps -ef grep java”，jps并不使用应用程序名来查找JVM实例。因此，它查找所有的Java应用程序，包括即使没有使用java执行体的那种（例如，定制的启动 器）。另外，jps仅查找当前用户的Java进程，而不是当前系统中的所有进程。
看泉子的一篇文章：JVM源码分析之Jstat工具原理完全解读 - 你假笨 里提到了两个JVM参数，可以控制perfdata文件是否共享，引用泉子对这两个参数的解释：
我们前面介绍了元空间的组成元素，但是没有将他们完整的串联起来，我们这里举一个简单的例子，将之前的所有元素串联起来。
在高并发下，Java程序的GC问题属于很典型的一类问题，带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」，由于GC期间都存在Stop The World问题，因此很容易导致服务超时，引发性能问题。
Flink 的 TaskManager 进程运行在 JVM 上，目前流计算 Oceanus 容器给定的内存上限是 4GB，如果超用就会被管控服务执行 OOMKilled。
这个常量是java进程存活时长阈值，当一个java进程存活时间大于此值时，才会被zabbix视为监控对象。此值的单位为秒。
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稳定增长，则有可能出现内存泄漏。
比较常用的参数： -q 只显示pid，不显示class名称,jar文件名和传递给main 方法的参数
本篇原文来自 LinkedIn 的 Zhenyun Zhuang，原文：Application Pauses When Running JVM Inside Linux Control Groups[1]，在容器化的进程中，或多或少会给现有应用程序带来一些问题，这篇文章讲的是 LinkedIn 在使用 cgroups 构建容器化产品过程中，发现资源限制策略对 Java 应用程序性能会产生一些影响，文章深入分析问题根本原因，并给出解决方案。笔者看过后，觉得非常赞，因此翻译后献给大家，希望对大家有帮助。
JVM 在执行 Java 应用程序时，将加载的 Java 类的许多细节记录在内存中，这些信息称为类元数据（Class MetaData）。这些元数据对于 Java 的很多灵活的语言以及虚拟机特性都是很重要的，比如动态类加载、JIT 实时编译、反射以及动态代理等等。不同的 JVM 加载类保存的内存信息是不一样的，它们通常在更低的内存占用与更快的执行速度之间进行权衡（类似于空间还是时间的权衡）。对于 OpenJDK Hotspot 使用的则是相对丰富的元数据模型来获得尽可能快的性能（时间优先，不影响速度的情况下尽量优化空间占用）。相比于 C,C++,Go 这些离线编译为可执行二进制文件的程序相比，像 JVM 这样的托管运行时动态解释执行或者编译执行的，则需要保留更多关于正在执行的代码的运行时信息。原因如下：
本篇原文来 LinkedIn 的 Zhenyun Zhuang，原文：Application Pauses When Running JVM Inside Linux Control Groups[1]，在容器化的进程中，或多或少会给现有应用程序带来一些问题，这篇文章讲的是 LinkedIn 在使用 cgroups 构建容器化产品过程中，发现资源限制策略对 Java 应用程序性能会产生一些影响，文章深入分析问题根本原因，并给出解决方案。笔者看过后，觉得非常赞，因此翻译后献给大家，希望对大家有帮助。
本文将详细介绍HotSpot的启动过程，启动过程涉及到的逻辑比较复杂，细节也比较多，为了让大家更快的了解这部分知识，我录制了对应的视频放到了B站上，大家可以参考。
最初，SQLlin 在 Kotlin/Native 平台上基于开源项目 SQLiter（见参考链接 1），目的是避免重复造轮子。虽然 SQLliter 是来自 Touchlab的优秀开源项目，但最近一年维护更新缓慢。在本文撰写时，SQLiter 于 2023 年 11 月发布了 1.3.0 和 1.3.1 两个版本（1.3.1升级到了 Kotlin 1.9.21，用于修复 1.9.20 的 Kotlin/Native 库版本号相关的问题）。但在这之前的版本，即 1.2.1 发布于 2022年 8 月，基于 Kotlin 1.6.20，一年以上没有更新。对于 2023 年的项目来说，1.6.20 过于老旧。老旧的版本导致了如下一些问题。
采用zip或tar.gz的二进制包方式安装的ES，需要配置一系列参数，通过阅读官方文档了解到其中重要参数的配置及其说，下面将逐步进行了解。
本篇原文作者是 LinkedIn 的 Swapnil Ghike，这篇文章讲述了 LinkedIn 的 Feed 产品的 GC 优化过程，虽然文章写作于 April 8, 2014，但其中的很多内容和知识点非常有参考意义。因此，翻译后献给各位同学。
折腾了两天总算搞定c调用jar包，其中遇到的问题这里总结一下： 1、起始demo 参考C调用java例子先跑起来 2、开发环境 使用linux虚拟机效率很低，找到了gnuwin32实现在windows下运行Makefile，使用的是https://sourceforge.net/projects/gnuwin32/ ，只需要把 mingw32-make.exe文件改名为make.exe 3、java开发 直接使用eclipse生成一个mvn项目，以这个最简项目开始入手 使用mvn编译出jar给c调用，参考maven将所有的依赖打成一个包，确保依赖没有问题，验证方法：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
