林明菁 https://blog.lxuan.fun/ 一个思念的人 Sun, 10 May 2026 02:53:12 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed zh-CN All rights reserved 2026, 林明菁 <![CDATA[JVM内存优化]]> https://blog.lxuan.fun/article/jvmncyh https://blog.lxuan.fun/article/jvmncyh Mon, 12 Jan 2026 00:00:00 GMT

栈溢出

栈溢出一般就是代码不当导致的，在 JVM的内存结构 中有讲到过，每个方法在调用时都会在本线程的栈中创建一个栈帧，每一个栈帧都会占用栈的一块内存空间，所以栈帧越大或者越多，就会出现栈溢出（StackOverflowError）。但这样说实在是有过浅显了，所以我们还是要问一句，为什么？
首先我要说第一个前提——JVM 的每一个栈帧的大小在方法调用时就确定了，是固定的，不会动态变化。
大家如果了解过 JVM 的内存结构就会知道，栈中放的都是大小已知的东西：局部变量表（全是基本变量）、操作数栈、方法出口（返回地址）、一些额外数据（栈帧指针等），因此栈帧的大小在方法调用前就已经根据 .class 文件（字节码）中的元数据确定了。每个方法都带着两个重要的属性：
  • max_locals —— 局部变量表大小
  • max_stack —— 操作数栈最大深度
例如：
编译后会确定：
  • max_locals = 3（a、b、c）
  • max_stack = 2（执行 a + b 时需要两个操作数）
这两个值是编译器编译时算出来的，因此无需在运行时动态扩张。
那么问题来了：既然栈帧的大小不会变，那么线程的栈同样也是栈，它的大小会变吗？
答案：不能，JVM 启动时指定每个线程栈大小（-Xss），每个线程创建时直接一次性申请这个大小的连续内存块，之后就不会动态扩张了。因此，当栈帧不断增多，很可能就会 " 撑爆 " 线程的栈，从而出现栈溢出，最简单的例子就是递归，每一个递归在 return 前它所占用内存空间都不会释放。
虽然说线程的栈的大小是固定的，但栈帧大小已知，那为什么线程不直接按 " 最大栈帧大小 × 最大调用深度 " 顶格分配？
首先有一个最大的问题：无法预先知道方法调用路径。JVM 不知道你在运行时会执行哪些方法、递归多深，甚至这个递归的深度可能会根据用户的输入而改变，这是运行时改变，还记得栈是线程创建时创建的吗，上一个因用户所带来的未知而出现的是 " 堆 "。
其次，即使我们确定了最大的一个栈帧的大小、规定了其最大递归深度，那也太太太浪费资源了，哪怕 Java 是企业级开发，内存相对而言不太紧张，但也正因为企业级的项目一不留神可能就会出现井喷式的 API 调用，以防用户使用不便，每一个线程和每一个 G 的内存都是宝贵的资源，更要细心一点 （说白了还是成本控制的问题）。

堆的垃圾回收

栈溢出的原因大多都是代码写的差，跟程序员交互的比较多，少写点垃圾代码就能解决。
因此内存优化主要还是看堆，首先照例说一下堆里存了哪些东西：创建的实例对象、数组以及字符串常量池。
开始说内存优化之前先来讲一下垃圾回收相关的知识，我们现在常用的 JDK 版本主要是 8、11、17。8 默认的垃圾收集器是 Parallel 和 Parallel Old，而 11 和 17 默认的是 G1，它们都是分代收集器，也就是会分为一个新生代和一个老年代，新生代的回收叫做 Minor GC，而老年代的回收叫做 Major GC，Minor GC 回收的频率非常快，而 Major GC 频率比较低，相比前者慢 10 倍。
我们先讲一下 Java 8 的收集器，分别是新生代的 Paralled 和老年代使用的 Parallel Old，新生代用的是复制算法，老年代用的是标记整理法，这些算法的概念参考 [[GC]] 或者 ChatGPT，详细就不说了。
这两个收集器尤其是新生代的，它的特点就是高吞吐量，什么是高吞吐量？比如说我现在吞吐量是 99，就代表一个虚拟机总共运行了 100 分钟，其中垃圾回收用了 1 分钟，实际干活的时间是 99 分钟，这就是吞吐量 99 的意思。与此相对会有个比较大的缺点——响应时间比较长，用户可能会出现长时间的卡顿，因为为了保证高吞吐量，他会一下子打扫干净，比如在 Eden 区和 Survivor From 区的垃圾会被一下子全部回收，也就是一次打扫的时间会比较久，这样就会导致 STM（所有应用程序暂停）时间会非常的长，垃圾收集器会独占 CPU 的资源，卡顿的频率不会很高，但是卡顿的时间可能会有点久，对于面向客户体验的系统，这个垃圾回收器就不是一个很好的选择。
而且在高并发的场景下，长时间 STW 可能会一下子堆积大量的请求，导致系统崩溃，也就是当我们在垃圾收集的时候，可能会发送大量的请求进来，因为垃圾收集器在工作的时候应用线程是不能执行任务的，所以请求都会卡在这个地方，等到垃圾回收结束，所有的请求会一下子涌入进来，就很容易导致系统崩溃。
当然 Paralle 依旧是热门收集器之一，除了高并发场景之外，发生问题或者影响用户体验的概率还是比较低的。
接着说一下 Java11 和 17 用的 G1，G1 整体上用的是标记整理算法，局部上用的是复制算法，他新生代和老年代的垃圾回收器都是用的 G1，那为什么还说它是分代收集器呢？因为它会把内存划分为 2048 个区域，即 region。每一个 region 可以是 Eden，也可以是 Survivor，也可以是 Old，所以它从概念上还是划分成新生代和老年代的。G1 整体上还是用的标记整理算法，但是它每一个 region，也就是每一个内存区域，用的是复制算法。
我们来简单说一下这个算法的流程：首先，G1 会根据每个 region 的回收价值，优先回收价值最高的 region（Eden），这也就是为什么叫 G1 的原因，one 代表 first。首先标记所有被选中的 region，比如选中了两个 Eden，它就会把这两个 region 中存活的对象先标记下来，将存货的对象复制到空闲的 region 中，这部操作体现了复制和整理。不同 region 中存活的对象集中复制到一个新的 region 中，这便是整理存活对象，最后就是把这两个旧 region 回收掉。
其实 G1 中的标记整理算法和复制算法与传统的还是有点区别的，思想上还是一致的，有兴趣的可以自己去了解一下。
G1 有两个显著的优势：第一个。因为 region 特别多，有 2048 个，如果每次要把所有的 region 都回收，这样造成 STW 时间就会很长，而回收价值最高的，这样就能保证垃圾收集的一个高效性；第二个。可以通过设置期望停顿时间，也就是 STW 时间是可以控制的，这样就能避免 Java8 中会出现的 Parallel 收集器响应时间过长的问题，用户也就能避免出现长时间卡顿的问题。
最后关于垃圾回收器还有一个概念————可达性分析。可达性分析说法有很多，我觉得最好理解的就是一个对象要有与之关联的引用，我在 ThreadLocal 这篇文章中提到过强引用和弱引用，我这里简述一下：当我们在堆中创建一个普通的对象的时候，创建它的线程同时也会在栈帧中的局部变量表中存放该对象的引用值 （这个引用值在 JVM 内部可能是一个句柄（Handle），通过句柄可以访问到堆内存中的对象信息。）。当这个方法结束，或者说栈帧结束的时候，局部变量表被清理，与之对应的引用就会消失，此时堆中的这个对象就可以被回收了，它也就不会被 G1 标记了。

JVM 调优

看了以上的内容，了解了大概，那么优化对你们来说就只是需要想。
优化可以从四个层面考虑：
  • 首先是新生代 GC 和老年代 GC 的执行时间，老年代 GC 时间很久，尽可能的减少老年代回收次数，同时还要保证新生代回收的稳定。
  • 其次是整个堆内存的大小，内存太小就容易导致 OOM，或者频繁发生 GC。
  • 根据业务的实际情况，选择适合程序的垃圾收集器。
  • Java 代码层面，控制生成对象的大小和数量。
以下是具体的调优方案：
  1. -Xmn：可以为应用程序分配一个合理的新生代空间，以最大限度避免新对象直接进去老年代。
      2. java -Xmn256m -jar application.jar
  1. -XX:+UseAdaptiveSizePolicy：开启 UseAdaptiveSizePolicy 动态调整 Survivor 区域，可以让新生代区动态的挪用部分老年代的内存，减少新生代回收次数；也可以防止新生代太小频繁 Minor GC 或者提前进入老年代，新生代太大，也会增加 Minor GC 的时间。
      2. java -XX:+UseAdaptiveSizePolicy -jar application.jar
  1. -XX:PretenureSizeThreshold：设置大对象直接进入老年代的阈值（单位是字节），当对象超过这个阈值时，将直接在老年代中分配。
      2. java -XX:PretenureSizeThreshold=1048576 -jar application.jar
  1. -XX:MaxTenuringThreshold：进入老年代的最大年龄值，每次存活下来年龄就会 +1，默认是 15，一些内存比较小的对象很多，可以增加最大年龄值，让这些小登对象尽可能一直留在新生代。
      2. java -XX:MaxTenuringThreshold=16 -jar application.jar
  1. -Xmx -Xms -XX:minheaoFreeRatio -XX:MaxHeapFreeRatio：设置堆的初始化大小、最大大小、堆最小空闲比例、堆最大空闲比例。
  1. -XX:+UseParallelGC：根据项目不同情况，选择合适的垃圾收集器，比如响应速度优先的 G1。
  1. 当我们知道哪些对象会在堆内存时，引用类型、数组、字符串，针对实际情况，减少这些对象的创建，或者减少这个对象占据内存的大小；当然还可以声明一些非强引用对象，这样也能避免 OOM。
]]> <![CDATA[共情是人类最伟大的情感]]> https://blog.lxuan.fun/article/gqsrlzwddqg https://blog.lxuan.fun/article/gqsrlzwddqg Thu, 18 Jul 2024 00:00:00 GMT

共情是人类最伟大的情感

高中时看完了《三体》三部曲，时至今日都仍然觉得很震撼，光怪陆离的科幻世界更是让我心潮澎湃，那时候最让我感兴趣的就是对三体人的描写，没有任何的外貌特征，仅仅四个字——“思想透明”，引来我无限遐想。
那时候我就在想：“思想透明”到底是什么样子的？又是什么感觉？没等我细细品味，翻书的手就打开了第三部。这本书出现了一个新的外星文明——歌者文明，在这个文明中上位者可以肆意翻阅下位者的记忆，就像翻阅着一本书籍。于是我又想了：记忆被翻阅是什么感觉？这样的文明又会是什么样子的？
假设有这样一个文明，这个文明中的所有个体都可以无视空间和时间共享记忆，那么这个群体是否已经可以被称之为一个个体呢？这个想法是我在看完《新世纪福音战士》这部动漫的时候诞生的，在这部动漫中，有一个被称之为“人类补完计划”的东西，当这个计划实现后所有人类都会归为一体，而同时每个人都将瞬间经历完所有人类的一生，人们互相理解、互相包容，人类再无隔阂。在记忆方面似乎有点类似三体文明和歌者文明，但不完全一样，至少这两个文明仍然是由群体构成的。
但那之前呢，《新世纪福音战士》中有十几个使徒，也叫做天使。每个使徒都有一道“A.T立场”，这道可以防御人类几乎一切武器的绝对领域，将每个使徒分隔为一个个个体，而人类也是一种使徒，但这份力量被分摊到拥有繁衍能力的人类身上就变得十分薄弱，仅仅只能隔开人的记忆和思想，然后我们便与三体人不同了。这个立场保护着我们的思想不受侵犯，在阿谀奉承时、在面对责骂批评时也都可以做到笑脸相迎，因为没人知道我们在想什么，就像蛋壳里的小鸡一样。但我们也失去了和别人感同身受的能力，我们没办法在别人嚎啕大哭时和他经历一样的悲伤，也没办法在别人幸福美满时和他经历一样的开心。哪怕别人竭尽全力去描述自己的伤心欲绝，与自己度过了四十年的深爱他的父母离去了，我们仍然不能感同身受——“我不是你，我怎会知道？”，是我们之间永远跨不过去的天堑。或许这一刻我理解了人类补完计划，这确实是一件令人悲伤的事情，补完后我即是你、你即是我，再无分别。我会理解过去欺凌我的人想法，他有着什么样的家庭？经历了什么样的人生？又有着什么样的朋友？我理解了过去杀人无数的死刑犯，他为什么要杀人？纯粹的恶意？毫无理由？身不由己？还是另有隐情？一切都无所遁形。我也理解了那些曾经深爱过我的人，他们是那样爱我，对我的无私奉献，给予我的安全感和满足感，毫无保留的呈现出来是那样的幸福。
但一切都没有任何意义了，我们此刻有着无限大的包容、无限大的理解，但却失去了彼此，我不再是我，你也不再是你。或许成为那样的神后也不会在意这些细枝末节，但想想还是算了吧，还是让力场将我们分开吧，其实这样也不错，既不像三体文明那样思想透明失去内心，也不像歌者文明那样记忆被肆意翻阅毫无遮拦，我们都有着自己的小世界，也谨慎地和别人共享着小世界。即使做不到完美的包容和理解，我也仍然可以做到看着你开心而为你开心、看着你伤心而为你伤心，尝试着与你一同经历着世间的一切，并与你一起感受。感谢人类的最伟大的共情能力，让我在你面前不会陌生地如同远在五万亿光年外的一只蚂蚁一般。
]]> <![CDATA[“动画化万岁！”]]> https://blog.lxuan.fun/article/dhhws https://blog.lxuan.fun/article/dhhws Fri, 11 Oct 2024 00:00:00 GMT

“动画化万岁！”

2017 年播出的《如果有妹妹就好了》是一部轻松搞笑的作品，然而其中也不乏对轻小说、漫画作者内心挣扎的刻画。作品里，作者自己的小说和漫画被改编成动画的情节引发了观众深思。虽说原作被改编为动画是许多作者梦寐以求的时刻，但在现实中，这个过程并不像想象中那样美好。
动画化，曾被视为作品成功的象征。然而，对于某些原作者来说，这个象征可能伴随着无尽的失望。动画制作是一个复杂的过程，涉及到原作、动画制作团队、市场和观众等多个方面。就像《如果有妹妹就好了》里讨论到的一样，原作被改编成动画后，结果往往无法达到作者预期，甚至可能让作品的整体质量大打折扣。这种情况会导致所谓的 " 动画党 "（只看动画的观众）对原作产生误解或负面评价，而这些评价又反过来打击了原作的声誉。
对于很多轻小说和漫画作者而言，动画化的风险不仅仅在于质量上的失控，还有原作声誉的损害。原作本身可能是经过作者多次打磨的心血之作，但当它进入动画化流程时，由于制作时间紧迫、预算限制和团队经验等原因，改编作品往往无法传达原作中的深刻细节和情感，甚至可能扭曲原作的核心。这种 " 劣质改编 " 让原作者感到无力，因为他们既无法干涉动画制作，又不得不面对粉丝对作品的失望与批评。一方面，作为创作者，他希望自己的作品被更多的人看到，渴望获得更高的关注度和认可；但另一方面，动画化带来的负面反馈却让他陷入低谷。这种负面影响不仅会打击创作的热情，还可能直接影响到作者未来的创作方向。很多时候，作者即便意识到这只是一次失败的改编，也难以轻易摆脱这种困扰，继续创作同样的作品可能会勾起对失败的回忆，放弃这条路则意味着此前努力的心血白费。
尽管动画化失败的风险让很多作者望而却步，但这并不意味着他们会因此停止创作。正如作品中的男二一样，面对种种挑战，创作者依然选择坚持下去，因为创作本身是他们的热情所在。这种热情不是因为一次动画化的失败而轻易泯灭。事实上，许多作者在经历了改编失败后，反而会更加坚定地追求创作的独立性和品质。他们意识到，改编终究只是作品传播的一个方式，而创作的初衷是无法被改变的。
总之，动画化对于许多轻小说和漫画作者来说既是梦寐以求的机会，也是让人心生畏惧的挑战。成功的动画化可以让作品焕发新生，而失败的改编则可能给创作者带来深深的失望和无奈。然而，无论如何，真正的创作者始终会坚持自己的道路，继续用心创作，超越那些外界的干扰与打击。正如《如果有妹妹就好了》中那样，创作的热情和信念才是他们前行的动力。
作为观众，当我们看到自己喜欢的作品宣布要动画化时，心中总会涌起难以抑制的兴奋。毕竟，原作不仅仅是文字和图画，而通过动画这种更加动态的媒介，故事与角色将获得全新的生命。这种期待不仅是因为对原作的深情厚爱，更是对动画化后的视听盛宴充满想象。于是，当喜爱的作品即将动画化时，我们感到双重的快乐：一份来自于原作本身的共鸣，另一份来自于即将呈现的新体验。
然而，这种兴奋常常伴随着一丝忐忑。毕竟，改编的质量无法预知。当我们怀着满心期待按下播放键，结果却看到画质崩坏、角色性格被曲解，或者剧情被粗暴地删减和修改时，内心的失落简直无法言喻。那种从高度期待到深深失望的转折，让人感到煎熬。一方面，作为原作党，我们清楚地知道作品原本的魅力；另一方面，眼前的改编却让人难以接受，甚至担心那些 " 只看动画 " 的观众会对原作产生误解。这种时刻，真是痛并难忍。
尽管如此，改编作品也有很多时候能带来意外的惊喜。有些动画不仅忠实于原作，还在叙事、人物塑造和情感表达上更加丰富。例如，通过优秀的配乐、精致的分镜和动人的声优表演，角色仿佛从纸面上活了起来。某些原作中的情感细节，因动画的表现手法被放大，让观众获得了比阅读时更强的情感冲击。这样的改编，反而让我们对原作有了更深的认识，同时也让更多人加入了对这个世界的喜爱之中。
有趣的是，原作党对作品的喜爱，有时并不仅仅基于其客观的质量，而是源自内心深处的某种共鸣。我们喜欢某部作品，不仅是因为它优秀，还因为它在某个特定的时刻打动了我们，让我们在角色的成长、情节的起伏中找到了自己的影子。这种情感共鸣，是为什么不同的作品吸引不同的人群。而这种喜爱是难以被量化的，它超越了制作的瑕疵，超越了理性的分析。这也是为什么，尽管改编有风险，动画化仍然能够激发观众无尽的期待。
此外，当我们看到自己深爱的作品被更多人熟知时，那种骄傲和喜悦是无可比拟的。讨论、分析、分享，看到其他观众因这部作品而感到快乐，就像我们当初的那份感动一样，令人倍感满足。即使改编不够完美，它依然让更多人了解并爱上了这个故事。动画化作为一种更大众化的传播媒介，给了这些作品从小众走向主流的机会。这种传播本身，或许就是一种成功。
对我来说，动画化的过程虽然充满未知与挑战，但它依然是我永远期待的旅程。每一部作品的改编，都是一次与更多观众分享我所热爱的机会。无论动画质量如何，只要有机会让更多人接触到这些宝贵的作品，何尝不是一件好事呢？失败固然令人遗憾，但那双重的快乐，永远值得去追逐。
最后一句，仅代表我个人而言，我永远期待着作品的改编，并且 " 动画化万岁！"
]]> <![CDATA[JWT]]> https://blog.lxuan.fun/article/JWT https://blog.lxuan.fun/article/JWT Mon, 20 Jan 2025 00:00:00 GMT

JWT

0 什么是 SSO

SSO（Single Sign On），中文翻译为单点登录，它是目前流行的企业业务整合的解决方案之一，SSO 的目标是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统，使用 SSO 整合后，只需要登录一次就可以进入多个系统，而不需要重新登录，这不仅仅带来了更好的用户体验，更重要的是降低了安全的风险和管理的消耗。
  • 为什么要用 SSO？
      • 现在流行的 Web 系统不断变的复杂，从最早的单系统单模块发展到现在的多系统多模块的应用群，用户在访问这些子系统或者分系统的时候，如果有 N 多个系统都要分别登录和登出，用户可能会疯掉。用户希望的是在这些系统中统一的登录和登出，换句话说，不管登录哪个系统之后，其他子系统就无需再登录了。
      举个实际应用的例子，比如微软的各个子系统，你会发现在浏览器不删除 Cookie 的情况下，登录官网后，再访问 OneDrive 是无需再登录的，这种方式就是单点登录 SSO 的应用。
      要实现单点登录，方式有很多，原理也名不相同，在这里主要讲主流的方案：使用 JWT 实现单点登录。
  • 前端用什么保存？
      • Cookie，Sessionstorage，Localstorage

1 什么是 JWT

官网：https://jwt.io/introduction
JSON Web Token 令牌 （JWT） 是一种开放标准（RFC 7519） 它定义了一种紧凑且自包含的方式，用于在各方之间作为 JSON 对象安全地传输信息，此信息可以验证和信任，因为它是经过数字签名的。JWT 可以使用密钥（使用 HMAC 算法）或使用 RSA 或 ECDSA 的公钥/私钥对进行签名，
通俗的说： JSON Web Token 简称即 JWT，也就是通过 JSON 形式的数据作为 Web 应用的令牌，用于在各方之间安全地将信息作为 JSON 对象传输。在数据传输过程中还可以完成数据加密，签名等相关处理。

2 JWT 工作流程

Authorization（授权）：这是使用 JWT 的最常见场景。一旦用户登录，后续每个请求都将包含 JWT，允许用户访问该令牌允许的路由、服务和资源。
流程上是这样的：
  1. 用户使用用户名密码来请求服务器
  1. 服务器进行验证用户的信息
  1. 服务器通过验证发送给用户一个 token
  1. 客户端存储 token，并在每次请求时携带上这个 token 值
  1. 服务端验证 token 值，并返回数据

3 JWT 长什么样

JWT 是由三段信息构成的，将这三段信息文本用 "." 链接在一起就构成了 JWT 字符串。就像这样：

3.1 第一部分——头部 （header）

JWT 的头部承载两部分信息：
  • 声明类型，这里是 jwt
  • 声明加密的算法，通常直接使用 HMAC SHA256
完整的头部就像下面这样的 JSON:
然后将头部进行 base64 加密，构成了第一部分：eyJOeXAioiJKV1QiLCJhbGcioiJIUzIINi]9

3.2 第二部分——载荷 （payload，类似于飞机上承载的物品）

载荷就是存放有效信息的地方。这个名字像是特指飞机上承载的货品，这些有效信息包含三个部分。
  • 标准注册的声明
  • 公共的声明
  • 私有的声明
标准中注册的声明（建议但不强制使用）：
  • iss: jwt 签发者
  • sub: jwt 所面向的用户
  • aud: 接收 jwt 的一方
  • exp: jwt 的过期时间，这个过期时间必须要大于签发时间
  • nbf: 定义在什么时间之前，该 jwt 都是不可用的
  • iat: jwt 的签发时间
  • jti: jwt 的唯一身份标识，主要用来作为一次性 token，从而回避重放攻击
公共的声明：
公共的声明可以添加任何的信息，一般添加用户的相关信息或淇他业务需要的必要信息但不建议添加敏感信息，因为该部分在客户端可解密。
私有的声明：
私有声明是提供者和消费者所共同定义的声明，一般不建议存放敏感信息，因为 bas64 是对称解密的，意味着该部分信息可以归类为明文信息。
定义一个 patload：用户信息
然后将其进行 base64 加密，得到 jwt 的第二部分：ey]zdWIioiIxM jMONTY30DkwIiwibmFtZSI6IkpvaG4gRG91IiwiYWRtaw4ionRydwv9

3.3 第三部分——签证 （signature）,

jwt 的第三部分是一个签证信息，这个签证信息由三部分组成：
  • header（base64 后的）
  • payload（base64 后的）
  • secret（盐）
这个部分需要 base64 加密后的 header 和 base64 加密后的 payload 使用 . 连接组成的字符串，然后通过 headere 中声明的加密方式进行加盐 secret 组合加密，然后 就构成了 jwt 的第三部分。
注意：secret 是保程在服务器端的，jwt 的签发生成也是在服务器端的，secret 就是用来进行 jwt 的签发和 jwt 的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个 secret，那就意味着客户端是可以自我签发 jwt 了。

补充：为什么JWT更适合分布式系统？

补充：Hutool工具包生成JWT

]]> <![CDATA[JVM的内存结构]]> https://blog.lxuan.fun/article/jvmdncjg https://blog.lxuan.fun/article/jvmdncjg Tue, 11 Nov 2025 00:00:00 GMT

JVM的内存结构

JVM 的内存结构分为 程序计数器、虚拟机栈、本地方法栈、元空间（方法区）、堆。
前三个是 线程隔离 的，后两个是 线程共享 的。

0 字节码

在介绍这五个区域之前，先得明白「字节码」是什么。
当 Java 项目被编译或启动时，.java 文件会被编译成 .class 文件，也就是 二进制格式的字节码文件，其中包含一条条字节码指令，例如：
对应的字节码指令如下：
^2cd2b7
这些字节码是一种 中间语言（中间指令集），是 JVM 的 " 母语 "，而非 CPU 的机器码 （常有新手搞错这一点）。
JVM 在执行时会把字节码 逐条解释或编译成机器码。
逐条翻译？这样岂不是会慢很多？没错，这确实会带来性能损耗，但正是因为有了 JVM 的这层抽象，Java 才能实现那句著名的口号——" 一次编写，到处运行"。
当然不止如此，JVM 重要的是能统一管理内存（GC）、提供安全沙箱、线程调度、异常处理、运行时监控接口，甚至能在不改源码的情况下自动优化（比如替换 GC 或 JIT 策略）。它本身就是一个专门为程序而生的系统。
如果直接编译成机器码，这些机制都无法实现。
其他语言为什么不选择 JVM 呢：
  • C/C++ 注重极致性能和底层控制；
  • Python 追求简洁易用；
  • .NET 有自己的 CLR；
  • Go、Rust 追求更快的启动和更小的部署体积。
JVM 的生态系统则更适合构建大型复杂的企业系统、大数据处理和移动端应用。
值得一提的是，现代 JVM（如 HotSpot、GraalVM）已经非常智能。
当某段代码被频繁执行时（即 热点代码），JVM 会触发 JIT 编译器（C1/C2），把这部分字节码编译成本地机器码，从而让 Java 实际运行速度非常接近甚至超过 C++。
以上，简单介绍了字节码指令。

1 元空间（方法区）

由 JVM 加载的 类信息、字节码指令、运行时常量池 等内容都存在于元空间中。（元空间并不在 JVM 中，而是使用了本地内存）。
既然在元空间中，那么元空间肯定是线程共享了。很好理解吧，毕竟代码可不能给每个线程复制一份，那空间全被代码浪费了，所以代码肯定是线程共享一份的，哪个线程需要什么功能就拿着输入在里面执行一遍，最后拿着结果走就行了。

1.1 类信息

字节码都懂了，但是这里的类信息是什么？有些教程中会把这两个分开，我这里也是便于解释，但其实它们都在 .class 文件里。说白了就是字面意思，它包含了类的结构信息，如类名、父类、接口、字段、方法、修饰符等。
看上面那段 代码，大家有没有发现字节码指令其实就是一个表格，按照顺序排列的表格实际上就是个数组，因此也有人称字节码指令为 字节码数组。那堆字节码，只是 " 代码实现 "，除此之外的类结构描述，就是类信息（元数据）。
还是上面的代码，大家应该知道没写全，写全的话应该是下面这样。
将这个文件真正转为 .class 文件，因为 .class 文件是二进制格式，所以真实样子是这样的。
反编译一下大概如下所示。
这样大家就明白了吧，其实只有最后这一块才是 System.out.println("Hi, I'm " + name) 真实的样子，除此之外，其他部分就是类的结构，也叫做类信息。

1.2 运行时常量池

看上面的字节码。虽然 .class 文件（直接称元空间即可）中也有 Constant pool ，但这个运行时常量池可不是大家常说的那个堆中的字符串常量池，运行时常量池中存放的是 字面量 和 符号引用。
类型
示例
含义
字面量
42、3.14
源码中的常量值
类符号引用
java/lang/StringBuilder
类的全限定名
字段符号引用
System.out
字段名及其描述符
方法符号引用
println:(Ljava/lang/String;)V
方法名与方法签名
字符串描述符 (Utf8)
"name"
标识符的名字（类名、字段名等）
为什么这些字面量放在元空间？因为这些常量永远不会变，它相当于属于这个代码的一部分，所以编译的时候直接嵌进去了 （除了字符串，存在于运行时常量池中的字符串在程序启动时都加载到堆中的字符串常量池）。举例如下。
类型
存放位置
final int COUNT = 10
元空间（常量内联）
final static int COUNT = 10
元空间（常量内联）
System.out.println("Hi, I'm") 中的 Hi, I'm
堆（字符串常量池）
final static String NAME = "Alice"
堆（字符串常量池）
static int age = 18
堆（类静态变量区）
static String msg = "Hi"
堆（类静态变量区 + 字符串常量池）
int id = 1（实例变量）
堆（对象实例中）
String name = "Tom"（实例变量）
堆（对象实例中 + 字符串常量池）
局部变量 int x = 5
栈帧
局部变量 String s = "Hi"
栈帧（引用）+ 堆（字符串）

1.2 静态变量（请看完再说）

有些人搞不懂静态变量到底在堆里还是元空间里，这个很好理解，静态变量是类的一部分，因此对于静态变量来说，这个引用变量、字段描述是很重要的，这些描述信息确实放在元空间里，但而创建的实例对象则在堆中（无论对象还是基本类型），随着类的加载而加载 （当然，堆会有一块区域专门属于类级别的存储区）。
记住一句话——元空间存放的是 " 关于类本身 " 的信息，不存放任何有关 " 值 " 这个概念的东西 （基本类型的常量算不算值？我觉得应该直接算作代码的一部分了）。
从 ChatGPT 那偷来一句话：

2 堆

介绍完元空间就顺带介绍一下堆，这玩意大家应该最不陌生了，它是真正存放 " 值 " 这个概念的地方。
堆是 JVM 中最大的一块内存区域，几乎所有对象都在这里分配。
它存放以下内容：
  • 所有的实例对象（包括数组、对象实例）；
  • 字符串常量池（JDK 7 以后迁移到堆）；
  • 静态变量的值（而非定义）；
  • 运行时常量池中引用到的动态内容。
堆是 线程共享 的，因此需要通过 GC（垃圾收集器）统一管理生命周期。

3 程序计数器

程序计数器是 每个线程私有的寄存器，用来记录当前执行的字节码指令的地址。它指向 " 下一条要执行的字节码 "，以便在方法切换、异常跳转时恢复执行。由于每个线程都有自己的执行路径，所以计数器必须线程隔离。

4 本地方法栈

本地方法栈用于支持 JVM 执行 Native 方法（本地方法），也就是那些用 C/C++ 等语言实现、通过 native 关键字声明的方法，比如 Object.hashCode()、System.arraycopy()。
它和虚拟机栈类似，也会为每个线程分配独立的栈空间，用于存储本地方法调用时的局部变量、返回地址和操作数栈等信息。
区别在于，虚拟机栈服务于 Java 方法执行，而本地方法栈服务于本地（Native）方法执行。
当 Java 调用到本地方法时，JVM 会通过 JNI（Java Native Interface） 进入本地方法栈，由本地语言代码执行，执行完毕后再返回 JVM 世界。在这个过程中，程序计数器也会记录对应的本地方法调用位置，以便能够正确恢复。

5 虚拟机栈

虚拟机栈，众所周知，栈和堆可谓是异父异母的非双胞胎结拜兄弟。
虚拟机栈用于描述 Java 方法的调用与执行过程，每个线程都有自己的虚拟机栈。
栈中每个方法的调用对应一个 栈帧（Stack Frame）。所有的字节码指令都只会对当前栈帧进行操作，如果这个方法内部调用了多个其他方法，就会出现多个其他栈帧。
JVM 直接对栈的操作只有两个：入栈和出栈，遵循先进后出原理。如：首先执行 Method01，则 Method01 会入栈进入虚拟机栈，而后调用 Method02，则 Method02 入栈进入虚拟机栈，等到 Method02 执行完 return 后就会出栈，接着回到 Method01 执行完 return 后也出栈。
了解了栈帧的概念，那就开始深入栈帧中的局部变量表、操作数栈、动态链接、方法出口、异常表这五个部分。

5.1 局部变量表

局部变量表存放的就是方法上的参数和方法内局部变量的值，方法中的这些值只有在这个方法执行的时候才会被加载到局部变量表中，需要注意的是，只有基本数据类型的值会被加载到局部变量表中，而字符串或者引用类型则是将地址加载到局部变量表中，通过地址在堆中就能找到值。
这很容易想通，Java 中的基本类型（int、double、boolean 等）在 JVM 中的大小是固定的，它们不包含复杂的内部结构，也没有引用关系，所以 JVM 知道这些变量在栈帧中应该分配多少空间，非常方便。并且每一次对其变量的值的修改也不会重新分配空间，而是直接覆盖这个槽里的值，这也是为什么基本类型会出现数据溢出的问题，JVM 定死了空间大小，栈也只会给出这么大的空间，想要扩展？想要更多空间？那就去堆吧。

5.2 操作数栈

操作数栈在方法执行过程中，根据字节码指令往操作数栈中写入数据或提取数据，如下所示。
这是一个方法：
这是 Method02 方法的字节码指令：
通过上面的例子我们可以看到，这些值会临时写入到操作数栈中，又把数据提取到局部变量表中，所以操作数栈的作用就是写入数据和提取数据。可以把操作数栈理解为草稿纸，程序执行时需要把这个值写道草稿纸上，计算后再将值写入到局部变量表中。

5.3 动态链接

动态链接保存了一个 " 符号引用 " 的编号，到运行时常量池 " 直接引用 "（全限定名）的内存地址的映射关系。直接引用就是元空间中运行时常量池存储的类和方法的全限定名。当在 Method01 中调用 Method02 时就会创建这样一条字节码指令：
因为动态链接保存了符号引用和直接引用的内存地址的映射关系，所以通过符号引用 #9 这个编号就能找到 Method02 这个方法的字节码指令的地址，并修改程序计数器保存的字节码指令的地址。
之前在说程序计数器的时候说过，它会记录下一条字节码指令的地址，所以原本要保存的 Method01 的字节码指令的地址，就会变成 Method02 开始的字节码指令地址。
那么问题来了，怎么返回上一个方法 Method01 呢？往下看。

5.4 方法出口

方法出口，存放调用该方法的指令的下一条指令的地址，这话听着有点抽象。
举个例子：Method01 调用 Method02 ，Method02 执行完最后一行代码后，应回到 Method01 继续执行。在调用 Method02 时，Method02 的栈帧的方法出口就记录了返回 Method01 后应继续执行的下一条字节码指令的地址，因此程序可以继续执行，或者可以说每个栈帧在结束后都会从方法出口出去。**（打个比方，字节码指令就如同一个个链表一样，程序计数器会记录下一个指令的地址，如果调用了其他方法就进入了新的链表，新的链表也走到头了，此时程序计数器就没有下一个指令的地址了，所以需要方法出口来作为新的链表的头节点）*

5.5 异常表

异常表——存放代码中异常的处理信息，有起始指令地址、结束指令地址、跳转指令地址。
比如此下面这段 try……catch。
进入这个方法时，这个方法的栈帧中就会存在类似这样的一张异常表。
Nr.
起始 PC
结束 PC
跳转 PC
捕获类型
0
5
8
11
cp_info #4 java/lang/Exception
起始 PC，即起始字节码指令地址，指开始捕获异常的字节码指令地址，也就是 try 下的第一个字节码指令地址，如：5 bipush 100；
结束 PC，即结束字节码指令地址，如果没有发生异常，try 与 catch 中间的最后一条字节码指令是一个跳转指令，如：8 goto 20 ，跳转到捕获异常结束的字节码指令地址，也就是 catch 结束的下一条字节码指令地址，在这个例子中，20 即 return，直接退出了方法体；
跳转 PC，即跳转字节码指令地址，如果 try 中出现了异常，就会根据异常表跳到 catch 开始的第一条字节码指令，如：11 astore_2，将 Exception 类型的局部变量 e 添加到局部变量表中的 2 位置。
]]> <![CDATA[ThreadLocal]]> https://blog.lxuan.fun/article/ThreadLocal https://blog.lxuan.fun/article/ThreadLocal Thu, 06 Feb 2025 00:00:00 GMT

ThreadLocal 底层实现

ThreadLocal 是 Java 中所提供的线程本地存储机制，可以利用该机制将数据 缓存在某个线程内部 ，该线程可以在任意时刻、任意方法中获取缓存的数据。
notion image
ThreadLocal 底层是通过 ThreadLocalMap 来实现的，每个 Thread 对象中都存在一个 ThreadLocalMap 变量，这个 Map 的 key 就是我们要操作的 ThreadLocal 对象，Map 的 value 为需要缓存的值。
我们在使用 ThreadLocal 的时候其实就是拿到当前线程中的 ThreadLocalMap 中的 key 和 value，ThreadLocal 本身不过是个工具类罢了。

注意事项

如果在线程池中使用 ThreadLocal 可能会造成内存泄漏，因为当 ThreadLocal 对象使用完之后，应该要把设置的 key 和 value——也就是 Entry 对象进行回收。但线程池中的线程不会回收，并且 Thread 对象是通过强引用指向 ThreadLocalMap，ThreadLocalMap 也是通过强引用指向 Entry 对象，线程不被回收，Entry 对象也就不会被回收，从而导致不再使用的 Entry 对象越来越多，出现内存泄漏。
解决办法是，在使用了 ThreadLocal 对象之后，手动调用 ThreadLocal 的 remove() 方法，手动清除 Entry 对象。
notion image
实线箭头是强引用，虚线箭头是弱引用
^4efc86
总结：当你在一个方法/栈中创建 ThreadLocal，该对象就被栈强引用着，直到方法执行完毕，栈被销毁，失去了强引用的、只有 ThreadLocalMap.Entry 弱引用的 ThreadLocal 就会被 GC 回收，但 ThreadLocalMap.Entry 中的 value 却实打实强引用了一个对象，entry 不死它就不死，所以说养成良好习惯 new ThreadLocal() 和 ThreadLocal.remove() 要在方法中成对出现。

应用场景

当一个变量是共享的（成员变量、static 等），但是需要每个线程互不影响，相互隔离，就可以使用 ThreadLocal。
  1. 跨层传递信息的时候，每个方法都声明一个参数很麻烦，A、B、C、D 4 个类互相传递，每个方法都声明参数降低了维护性，可以用一个 ThreadLocal 共享变量，在 A 存值， B、C、D 都可以获取。
  1. 隔离线程，存储一些线程不安全的工具对象，如（SimpleDateFormat）。
  1. Spring 中的事务管理器就是使用的 ThreadLocal，这也是为什么声明式事务如果用到了多线程，它是没有办法达到一致性的，因为一个线程就存储了一个事务。
  1. SpringMVC 的 HttpSession、HttpServletReuqest、HttpServletResponse 都是放在 ThreadLocal，因为 servlet 是单例的，而 SpringMVC 允许在 controller 类中通过@Autowired 配置 request、response 以及 requestcontexts 等实例对象，在任何地方获取请求都永远是当前的请求。底层就是搭配 ThreadLocal 才实现线程安全。
]]>