From 0f2ae003aa1e435411c76af7aaa8b1a1027549d3 Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Mon, 16 Jun 2025 15:49:21 +0800
Subject: [PATCH 1/9] =?UTF-8?q?=E6=A0=BC=E5=BC=8F=E5=8C=96?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...45\215\201\345\244\247\345\273\272\350\256\256.md" | 11 +++++++++--
 ...47\250\213\345\221\250\346\212\245\344\272\214.md" |  5 ++---
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git "a/\347\250\213\345\272\217\344\272\272\347\224\237&\351\235\242\350\257\225\345\273\272\350\256\256/\351\207\221\344\270\211\351\223\266\345\233\233\357\274\214\347\273\231\351\235\242\350\257\225\350\200\205\347\232\204\345\215\201\345\244\247\345\273\272\350\256\256.md" "b/\347\250\213\345\272\217\344\272\272\347\224\237&\351\235\242\350\257\225\345\273\272\350\256\256/\351\207\221\344\270\211\351\223\266\345\233\233\357\274\214\347\273\231\351\235\242\350\257\225\350\200\205\347\232\204\345\215\201\345\244\247\345\273\272\350\256\256.md"
index 6909f79..79673b9 100644
--- "a/\347\250\213\345\272\217\344\272\272\347\224\237&\351\235\242\350\257\225\345\273\272\350\256\256/\351\207\221\344\270\211\351\223\266\345\233\233\357\274\214\347\273\231\351\235\242\350\257\225\350\200\205\347\232\204\345\215\201\345\244\247\345\273\272\350\256\256.md"
+++ "b/\347\250\213\345\272\217\344\272\272\347\224\237&\351\235\242\350\257\225\345\273\272\350\256\256/\351\207\221\344\270\211\351\223\266\345\233\233\357\274\214\347\273\231\351\235\242\350\257\225\350\200\205\347\232\204\345\215\201\345\244\247\345\273\272\350\256\256.md"
@@ -1,4 +1,5 @@
 ### 一、提前复习好你的专业知识
+
 专业知识是最为重要的一点，拥有了坚实的专业基础，你才能迈向成功的彼岸。
 
 因此，面试之前，一定一定要复习好专业知识。对自己学过的知识，要做一个概括，放在脑海中。茶余饭后，复习一下，做到随便看到一道基础题目，心中都能有个答案。
@@ -9,6 +10,7 @@
 ![](https://user-gold-cdn.xitu.io/2020/2/14/17043f9e65f6c1a2?w=1919&h=1080&f=png&s=1153224)
 
 ### 二、对简历上写的项目一定要足够了解，把握其中的亮点。
+
 你在简历上的信息，就是面试官了解你的窗口。你写上去的项目，自己一定一定要了解清楚来龙去脉。如果把别人很厉害的项目copy上去，面试官一问你三不知，那就露馅啦~
 
 同时，简历上需要沉淀一些有内容的东西，需要有些亮点。当然，简历上的亮点并不一定是酝酿百年的女儿红，也可以是你自己含辛茹苦酿造出的米酒，只要有你汗水的味道体现在里面就可以啦。
@@ -19,8 +21,8 @@
 
 [CAS乐观锁解决并发问题的一次实践](https://juejin.im/post/5d0616ade51d457756536791)
 
-
 ### 三、面试一定要杜绝过度紧张，要心平气和去对待。
+
 面试过程一定要杜绝过度紧张，紧张可能会导致你发挥失常，让你基础的问题都忘了怎么回答，最后与理想offer失之交臂。
 
 有点小紧张也是可以接受的，这一点会促使你认真地准备，但是过度紧张就适得其反啦。
@@ -29,7 +31,9 @@
 
 平时如果觉得生活压抑，或者紧张的话，我会弹弹吉他，唱唱歌，哈哈
 ![](https://user-gold-cdn.xitu.io/2020/2/14/17043f1531a9fc6e?w=1080&h=2248&f=png&s=580499)
+
 ### 四、面试前充分了解公司以及工作岗位内容
+
 面试前，多点了解公司是做什么业务的，以及工作岗位的主要工作内容。结合招聘要求，提前想一下面试官可能问的问题，换位思考以及延伸思考。比如，你面的是一间银行的开发岗，该银行用到自研的MQ通讯，那么，你需要准备好https相关的面试题，消息中间件的相关面试题等等。
 
 如：https原理是什么？谈谈RocketMQ消息顺序和重复消费问题等。
@@ -50,7 +54,6 @@
 如果你要面一个大厂，有认识的人内推最好不过啦，其实内推过得概率大很多的。因为，大家都懂一个道理，优秀的人旁边，也是一些优秀的人，正所谓**物以类聚，人以群分**。
 所以，多数HR也是这样挑人的，如果你通过内推获得面试机会，好好表现吧，骚年。
 
-
 ![](https://user-gold-cdn.xitu.io/2020/2/14/1704426243d9ab07?w=255&h=255&f=png&s=104800)
 
 ### 七、在工作时一点一字积累，在面试时，一字一词表现。
@@ -60,15 +63,19 @@
 比如，一下是我工作中代码细节的总结，有兴趣可以看看哈~
 
 [写代码有这些想法，同事才不会认为你是复制粘贴程序员](https://juejin.im/post/5dfe2e72518825125f39a2de)
+
 ### 八、面试尽量拿多几个offer，这样才能掌握主动权，不然HR可能会压榨你。
+
 面试找工作，对待offer。需要吃着碗里的，看着锅里的。要不然，如果你只有一个offer，HR跟你谈薪的时候，很可能会压榨你的价值。拿多几个offer，可以有谈薪的资本。
 
 ![](https://user-gold-cdn.xitu.io/2020/2/14/1704423b8e7982ac?w=800&h=450&f=png&s=613615)
 
 ### 九、多点刷专业笔试题，程序员的话，争取成为leetcode的常客。
+
 阿里、腾讯、头条这些公司，面试经常要求手动写编程题，所以，作为面试者，要想过关，一定需要多点刷题，尤其是leetcode官网上面的题，不求每道题都能背下来，但是至少，每种类型的题目，你都需要知道思路，需要知道大概怎么实现吧，如：动态规划问题、链表操作等等。
 
 ### 十、学习一门乐器，坚持一项运动。
+
 学习一门乐器，是为了让生活多一份诗意，坚持一项运动，是为了身体健康。
 
 学习一门乐器，在面试官看来会加分的，因为年会可以上去表演哈哈~ 坚持一项运动，也是加分的，因为一般公司都有运动小组，篮球小组，或者羽毛球，如果面试官也跟你一样爱好篮球，说不定，你们就可以聊聊今年湖人总冠军了，哈哈。并且，运动的人最阳光啦，哈哈，不信你看我~
diff --git "a/\350\214\266\344\275\231\351\245\255\345\220\216\350\260\210\347\274\226\347\250\213\345\255\246\344\271\240\345\221\250\346\212\245/\350\214\266\344\275\231\351\245\255\345\220\216\347\274\226\347\250\213\345\221\250\346\212\245\344\272\214.md" "b/\350\214\266\344\275\231\351\245\255\345\220\216\350\260\210\347\274\226\347\250\213\345\255\246\344\271\240\345\221\250\346\212\245/\350\214\266\344\275\231\351\245\255\345\220\216\347\274\226\347\250\213\345\221\250\346\212\245\344\272\214.md"
index b5bb492..82e3b5a 100644
--- "a/\350\214\266\344\275\231\351\245\255\345\220\216\350\260\210\347\274\226\347\250\213\345\255\246\344\271\240\345\221\250\346\212\245/\350\214\266\344\275\231\351\245\255\345\220\216\347\274\226\347\250\213\345\221\250\346\212\245\344\272\214.md"
+++ "b/\350\214\266\344\275\231\351\245\255\345\220\216\350\260\210\347\274\226\347\250\213\345\255\246\344\271\240\345\221\250\346\212\245/\350\214\266\344\275\231\351\245\255\345\220\216\347\274\226\347\250\213\345\221\250\346\212\245\344\272\214.md"
@@ -4,6 +4,7 @@
 当qps在1000的时候，由于一个请求我需要分成三次去请求不同的接口，就相当于有3000个调用接口的请求。  但是请求用的是实时接口，如果该接口响应很慢比如10秒钟，那么这147个线程就全部挂起了，没有空余的线程去处理新的业务了。整个系统的响应就非常慢了。
 
 群上回复答案：
+
 > - 响应很慢的接口走异步，把返回的数据丢到queue里面。
 > - 应该是10秒的接口得改
 > - 接口慢了的话，看下能不能用redis 
@@ -14,14 +15,12 @@
 
 ![](https://imgkr2.cn-bj.ufileos.com/5f138381-05f3-4aa2-a344-98e8b970a920.png?UCloudPublicKey=TOKEN_8d8b72be-579a-4e83-bfd0-5f6ce1546f13&Signature=yJuf5adRW5I%252BSl3%252FWX1oyVr9%252Ffo%253D&Expires=1603008626)
 
-
 其实，如果每个请求30毫秒处理完，可能你的线程池也够用了。但是呢，如果你一个请求，接口处理10s，也就是说10秒，它没干完活，没法接别的活，肯定系统就处理不过来那么多请求啦，所以最后结果就是，一部分请求就会抛弃，因为线程池抛弃策略抛弃啦。回过头，你的系统响应慢，就是你的接口耗时问题呀，你需要优化它。
 
 可以看下我这两篇文章。线程池和如何接口性能优化的~
 
-
-
 关于线程池和接口性能优化的，可以看下我之前这两篇文章哈
+
 - [面试必备：Java线程池解析](https://mp.weixin.qq.com/s?__biz=MzIwOTE2MzU4NA==&mid=2247483728&idx=1&sn=0221dfd5eb7862c0aa749a7038b39307&chksm=9779457fa00ecc69d3bb554ccc1daa8aa204b16b15587759cf1f148bda51907f6f57418e150f&token=1319249232&lang=zh_CN#rd)
 
 - [记一次接口性能优化实践总结：优化接口性能的八个建议](https://mp.weixin.qq.com/s?__biz=MzIwOTE2MzU4NA==&mid=2247484426&idx=1&sn=7265be5a5c37e71e65a2e42c999d3f72&chksm=97794025a00ec93379ad537353dd58f9149f801e100786a2b9c8cf37257e6d863d7ce4b87a5e&token=1319249232&lang=zh_CN#rd)
\ No newline at end of file

From 26d835466288cfed5ae240150981f0cfd2615c5d Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Tue, 24 Jun 2025 10:03:23 +0800
Subject: [PATCH 2/9] =?UTF-8?q?=E7=BC=96=E7=A0=81?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...VM\351\235\242\350\257\225\351\242\230.md" | 104 +++++++++---------
 1 file changed, 52 insertions(+), 52 deletions(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md"
index 5bda042..6379be6 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md"	
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md"	
@@ -1,52 +1,52 @@
-### JVM ƪ
-1. ʲô����»ᷢ��ջ�ڴ������ʲôʱ�����������������ô�Ŵ��ģ�
-2. JVM��ô�ж϶����ǿɻ��ն�������Щ������
-3. JVM���ڴ�ṹ����������������ı�����Eden��Survivor������
-4. ��֪���ļ��������ռ��������Ե���ȱ�㣬�ص㽲��cms��G1������ԭ�������̣���ȱ�㡣
-5. ��˵˵���˽��������������Դ���˫��ί��ô����ô���ơ�
-6. JVM�ڴ�ΪʲôҪ�ֳ�����������������־ô�����������ΪʲôҪ��ΪEden��Survivor��
-7. JVM ���� fullGC ��Ƶ������ôȥ�����Ų����⣿
-8. JVM��һ��������GC�����������ģ�������ν������������˵˵��֪���ļ�����Ҫ��JVM������
-9. ���������㷨��ʵ��ԭ����
-10. JVM�ڴ�ģ�͵����֪ʶ�˽���٣������������ڴ����ϣ�happen-before�����ڴ棬�����ڴ�ȡ�
-11. ˵һ��Java����Ĵ�������
-12. ��������Ӧ�õ�JVM������������Щ��
-13. G1��cms����
-14. ��ô����߳�ջ��Ϣ��
-15. ˵һ������ص�ִ�й���
-16. JVM�������ջ��ƣ���ʱ����MinorGC�Ȳ����أ�
-17. ZGC �����ռ������˽����
-18. ����ķ��ʶ�λ�������ַ�ʽ?
-19. ˵һ�� jvm ���ŵĹ��ߣ�
-20. ����ʲôʱ�������������
-21. �ڴ�й©���ڴ��������
-22. ʲô��tomcat����ػ��ƣ�
-23. �˽����ݷ���������
-24. ����System.gc()�ᷢ��ʲô?
-25. ̸̸Minor GC������full GC����
-26. Stop The World �˽����
-27. ̸̸����ʶ������OOM����α���OOM?
-28. �˽��JVM����û������˼·��ʲô?���ȷ�����ǵĴ�С�أ�
-29. �Ա�������Ʒ��Ϣ��JVM�ĸ��ڴ�����
-30. �ֽ���ı������
-31. Java��Ҫ������Ա�����ڴ�������
-32. Java������������ʲôĿ�ģ�ʲôʱ������������գ�
-33. System.gc()��Runtime.gc()����ʲô���飿
-34. ���ڴ��빤���ڴ�
-35. �ڴ�佻������
-36. volatile ��ֹ�ڴ�������
-37. �ڴ�ģ����������
-38. ̸̸���з���ԭ��
-39.  JVM ���ڴ�����������߳��Ƿ�ɼ���������
-40.  ˵һ��JVM ���ò�������Щ��
-41.  VM Ϊʲôʹ��Ԫ�ռ��滻�����ô���
-42.  Java�ѵĽṹ��ʲô���ӵģ�ʲô�Ƕ��е����ô�(Perm Gen space)?
-43.  JVM�����ô��лᷢ����������ô��
-44.  ʲô���ֽ��룿�����ֽ�������ô���ʲô��ʲôJava���������
-45.  MinorGC ����
-46.  CPU ռ�ù�����η���
-47.  Serial��Parallel GC֮��IJ�֮ͬ����
-48.  WeakHashMap ����ô�����ģ�
-49.  ���� Java �ѿռ估 GC��
-50.  ���ܱ�֤ GC ִ����
-51.  JVM���ĸ����������������̵߳�ջ��ջС��?
+### JVM 篇
+1. 什么情况下会发生栈内存溢出。什么时候发生堆溢出？你是怎么排错的？
+2. JVM怎么判断对象是可回收对象？有哪些方法。
+3. JVM的内存结构，新生代与老年代的比例，Eden和Survivor比例。
+4. 你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，包括原理，流程，优缺点。
+5. 简单说说你了解的类加载器，可以打破双亲委派么，怎么打破。
+6. JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和Survivor。
+7. JVM 出现 fullGC 很频繁，怎么去线上排查问题？
+8. JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代，说说你知道的几种主要的JVM参数。
+9. 垃圾回收算法的实现原理。
+10. JVM内存模型的相关知识了解多少，比如重排序，内存屏障，happen-before，主内存，工作内存等。
+11. 说一下Java对象的创建过程
+12. 你们线上应用的JVM参数配置了哪些。
+13. G1和cms区别。
+14. 怎么打出线程栈信息。
+15. 说一下类加载的执行过程
+16. JVM垃圾回收机制，何时触发MinorGC等操作呢？
+17. ZGC 垃圾收集器，了解过吗
+18. 对象的访问定位有哪两种方式?
+19. 说一下 jvm 调优的工具？
+20. 对象什么时候会进入老年代？
+21. 内存泄漏和内存溢出区别？
+22. 什么是tomcat类加载机制？
+23. 了解逃逸分析技术吗
+24. 调用System.gc()会发生什么?
+25. 谈谈Minor GC条件，full GC条件
+26. Stop The World 了解过吗？
+27. 谈谈你认识多少种OOM？如何避免OOM?
+28. 了解过JVM调优没，基本思路是什么?如何确定它们的大小呢？
+29. 淘宝热门商品信息在JVM哪个内存区域
+30. 字节码的编译过程
+31. Java需要开发人员回收内存垃圾吗？
+32. Java中垃圾回收有什么目的？什么时候进行垃圾回收？
+33. System.gc()和Runtime.gc()会做什么事情？
+34. 主内存与工作内存
+35. 内存间交互操作
+36. volatile 禁止内存重排序
+37. 内存模型三大特性
+38. 谈谈先行发生原则
+39.  JVM 堆内存溢出后，其他线程是否可继续工作？
+40.  说一下JVM 常用参数有哪些？
+41.  VM 为什么使用元空间替换了永久代？
+42.  Java堆的结构是什么样子的？什么是堆中的永久代(Perm Gen space)?
+43.  JVM的永久代中会发生垃圾回收么？
+44.  什么是字节码？采用字节码的最大好处是什么？什么Java是虚拟机？
+45.  MinorGC 的过程
+46.  CPU 占用过高如何分析
+47.  Serial与Parallel GC之间的不同之处？
+48.  WeakHashMap 是怎么工作的？
+49.  解释 Java 堆空间及 GC？
+50.  你能保证 GC 执行吗？
+51.  JVM中哪个参数是用来控制线程的栈堆栈小的?

From 3ce15404034ff40a13ba03d1bcd4a3c879bdf3d2 Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Tue, 24 Jun 2025 10:07:20 +0800
Subject: [PATCH 3/9] =?UTF-8?q?=E8=A1=A5=E5=85=85=E7=AD=94=E6=A1=88?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...VM\351\235\242\350\257\225\351\242\230.md" | 703 +++++++++++++++++-
 1 file changed, 684 insertions(+), 19 deletions(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md"
index 6379be6..2eef813 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md"	
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/JVM \347\257\207/JVM\351\235\242\350\257\225\351\242\230.md"	
@@ -1,52 +1,717 @@
 ### JVM 篇
 1. 什么情况下会发生栈内存溢出。什么时候发生堆溢出？你是怎么排错的？
+   答：栈内存溢出通常发生在以下情况：
+    * 递归调用过深，没有正确终止条件，导致栈帧不断压入栈而栈空间耗尽。
+    * 局部变量过多或过大，单个方法调用时栈帧超过栈容量限制。
+    * 线程创建过多，每个线程都有独立的栈空间，总栈空间耗尽。
+      堆溢出通常发生在：
+    * 程序申请的内存总量超过了JVM堆的最大容量（-Xmx设置）。
+    * 发生了内存泄漏（Memory Leak），对象不再被使用但仍然被引用，导致可用堆空间逐渐耗尽。
+      排错方法：
+    * **栈溢出**：
+        * 使用JVM参数 `-XX:+PrintStackTrace` 打印出完整的异常堆栈信息，定位到具体的代码行。
+        * 检查递归逻辑，确保有终止条件。
+        * 检查方法内局部变量数量和大小。
+        * 调整JVM栈大小参数 `-Xss`（但通常不是首选，应先优化代码）。
+    * **堆溢出**：
+        * 捕获 `OutOfMemoryError` 异常，在异常处理中 dump 堆转储文件（Heap Dump），常用参数 `-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump.hprof`。
+        * 使用分析工具（如VisualVM, Eclipse MAT, JProfiler, YourKit）加载Heap Dump文件，分析内存占用情况，查找内存泄漏点（如哪些对象占用大量内存，哪些GC Roots引用了它们）。
+        * 分析GC日志（`-Xlog:gc*=info`），观察内存增长趋势和Full GC情况，判断是内存泄漏还是堆大小设置不当。
 2. JVM怎么判断对象是可回收对象？有哪些方法。
+   答：JVM主要通过以下两种方法判断对象是否可回收：
+    * **引用计数法（Reference Counting）**：为每个对象分配一个引用计数器。当有一个地方引用它时，计数器加1；引用失效时，计数器减1。任何时刻计数器为0的对象就是不可能再被使用的，可以被回收。缺点是难以解决对象间的循环引用问题。
+    * **可达性分析算法（Reachability Analysis / Tracing Algorithm）**：这是目前主流的判断方法。通过一系列称为“GC Roots”的对象作为起点，向下搜索，如果一个对象到GC Roots没有任何引用链相连（即从GC Roots到该对象不可达），则证明该对象是不可用的，可以被回收。可以作为GC Roots的对象包括：虚拟机栈（栈帧中的本地变量表）中引用的对象、方法区中类静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI（Native方法）引用的对象等。
 3. JVM的内存结构，新生代与老年代的比例，Eden和Survivor比例。
+   答：JVM内存结构（以HotSpot为例）主要分为：
+    * **堆（Heap）**：几乎所有的对象实例都在这里分配内存，是GC的主要区域，可细分为新生代和老年代。
+    * **栈（Stack）**：每个线程创建时都会分配一个私有的栈，用于存储局部变量、操作数栈、动态链接、方法出口等信息。栈内存是线程私有的。
+    * **程序计数器（Program Counter Register）**：指示当前线程执行的字节码指令地址，也是线程私有的。
+    * **本地方法栈（Native Method Stack）**：为JVM使用到的Native方法服务，也是线程私有的。
+    * **方法区（Method Area）/元空间（Metaspace）**：存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。在JDK 7及之前是永久代（PermGen），JDK 8及之后改为元空间（Metaspace），元空间使用本地内存。
+      新生代与老年代的比例：默认是 **1:2**，即新生代占堆内存的1/3，老年代占2/3。可以通过 `-XX:NewRatio` 参数调整（例如 `-XX:NewRatio=2` 表示老年代:新生代=2:1）。
+      Eden和Survivor比例：新生代内部又分为一个Eden空间和两个Survivor空间（From和To）。默认比例是 **Eden : Survivor = 8 : 1 : 1**。可以通过 `-XX:SurvivorRatio` 参数调整（例如 `-XX:SurvivorRatio=8` 表示Eden:Survivor=8:1）。
 4. 你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，包括原理，流程，优缺点。
+   答：常见的垃圾收集器有：
+    * **Serial GC**：单线程收集器，进行垃圾回收时必须暂停所有用户线程（Stop The World, STW）。优点是简单高效（在单核CPU上），内存开销小。缺点是STW时间长，不适合服务器环境。
+    * **ParNew GC**：Serial GC的多线程版本，使用多个GC线程并行回收。是许多Server模式下的首选新生代收集器，可以与CMS配合使用。优点是并行回收，减少STW时间。缺点是仍然是独占式回收，且需要多核CPU支持。
+    * **Parallel Scavenge GC**：新生代收集器，使用复制算法，追求高吞吐量（Throughput = 用户代码运行时间 / (用户代码运行时间 + GC时间)）。可以通过 `-XX:MaxGCPauseMillis` 设置最大暂停时间目标，但效果有限。优点是吞吐量高。缺点是STW时间可能较长，无法精确控制暂停时间。
+    * **Serial Old GC**：Serial GC的老年代版本，使用标记-整理算法。用于Client模式或Parallel Scavenge的后备方案。
+    * **Parallel Old GC**：Parallel Scavenge的老年代版本，使用标记-整理算法。优点是高吞吐量，且老年代回收也能并行。缺点是STW时间可能较长。
+    * **CMS（Concurrent Mark Sweep）GC**：
+        * **原理**：一种以获取最短回收停顿时间为目标的收集器，基于“标记-清除”算法实现。主要优点是并发标记和并发清除，大部分工作不阻塞用户线程。
+        * **流程**：
+            1.  **初始标记（Initial Mark）**：STW，标记GC Roots能直接关联到的对象。速度很快。
+            2.  **并发标记（Concurrent Mark）**：在用户线程继续运行的同时，从GC Roots开始遍历整个对象图，标记所有可达对象。耗时较长但不需要STW。
+            3.  **重新标记（Remark）**：STW，修正并发标记期间因用户线程继续运行而导致标记产生变动的那部分对象的标记记录。这个阶段停顿时间比初始标记长，但远比并发标记短。
+            4.  **并发清除（Concurrent Sweep）**：在用户线程继续运行的同时，清除掉未被标记（不可达）的对象。由于是“标记-清除”算法，会产生内存碎片。
+        * **优缺点**：
+            * 优点：并发收集，低停顿。
+            * 缺点：对CPU资源敏感（并发阶段虽然不暂停用户线程，但会占用CPU资源影响应用性能）；无法处理“浮动垃圾”（并发标记和清除期间用户线程产生的垃圾，只能等到下一次GC）；内存碎片问题（可能导致大对象分配时需要触发Full GC）。
+    * **G1（Garbage-First）GC**：
+        * **原理**：一款面向服务器的垃圾收集器，主要针对多处理器、大内存的机器，在有限停顿时间内获得高吞吐量。它将整个堆划分为多个大小相等的独立区域（Region），每个Region都可以扮演Eden、Survivor或Old的角色。它跟踪各个Region的垃圾价值（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的停顿时间，优先回收价值最大的Region。
+        * **流程**：
+            1.  **初始标记（Initial Mark）**：STW，与CMS的初始标记类似，标记GC Roots直接关联的对象，但可以利用Remark时收集的引用信息。
+            2.  **并发标记（Concurrent Mark）**：与CMS类似，遍历对象图，标记所有可达对象，并计算各个Region的回收价值。
+            3.  **最终标记（Final Mark）**：STW，处理并发标记期间对象引用关系变化的部分。
+            4.  **筛选回收（Cleanup）**：STW，根据并发标记的结果，筛选出回收价值高、且预计停顿时间满足要求的Region集合，进行回收。回收时，将Region中存活的对象复制到空的Region中，并清除被回收Region的空间。这个过程会整理内存，减少碎片。
+        * **优缺点**：
+            * 优点：可预测的停顿时间（通过 `-XX:MaxGCPauseMillis` 设置目标），高吞吐量，能充分利用多CPU优势，有效解决内存碎片问题，可扩展性好（适用于大内存）。
+            * 缺点：相对复杂，内存占用稍高（需要维护数据结构），在Region数量较少或对象大小分布不均时可能不如CMS。
 5. 简单说说你了解的类加载器，可以打破双亲委派么，怎么打破。
+   答：类加载器负责将类的字节码文件（.class）加载到JVM中，并生成对应的Class对象。常见的类加载器有：
+    * **启动类加载器（Bootstrap ClassLoader）**：负责加载 `<JRE_HOME>/lib` 目录下或被 `-Xbootclasspath` 参数指定的核心类库（如rt.jar）。它是C/C++实现的，Java程序无法直接获取其引用。
+    * **扩展类加载器（Extension ClassLoader）**：负责加载 `<JRE_HOME>/lib/ext` 目录下或被 `java.ext.dirs` 系统变量指定的扩展类库。
+    * **应用程序类加载器（Application ClassLoader / System ClassLoader）**：负责加载 `CLASSPATH` 环境变量或 `-classpath` 指定的类路径下的类。它是我们编写的大多数应用程序的默认类加载器。
+    * **自定义类加载器**：继承 `java.lang.ClassLoader` 并重写 `findClass`（或 `loadClass`）方法实现。
+      **双亲委派模型（Parent Delegation Model）**：工作流程是：如果一个类加载器收到了加载类的请求，它首先不会自己尝试加载，而是将请求委派给它的父类加载器。只有当父类加载器反馈自己无法完成加载任务时（如父类加载器中不存在该类），子类加载器才会尝试自己去加载。
+      **打破双亲委派**：可以打破，但需要手动干预。常见的方法有：
+    * **重写 `loadClass` 方法**：在自定义类加载器中，不遵循双亲委派的逻辑，直接调用 `findClass` 方法进行加载。
+    * **重写 `findClass` 方法**：这是更推荐的方式。在自定义类加载器的 `findClass` 方法中实现自己的加载逻辑（如从网络、数据库等非标准位置加载），并确保在找不到类时抛出 `ClassNotFoundException`，这样调用链上的其他加载器（包括父加载器）还有机会尝试加载。
+    * **使用 `ClassLoader#loadClass(String, boolean)` 的 `resolve` 参数**：虽然不直接打破模型，但可以控制是否解析类。
+    * **线程上下文类加载器（Thread Context ClassLoader）**：通过 `Thread.setContextClassLoader()` 设置，可以在类加载链路中插入一个不同的加载器。例如，JNDI服务使用它来加载资源，打破了SPI（Service Provider Interface）场景下默认的双亲委派限制。
 6. JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和Survivor。
+   答：
+    * **为什么分新生代和老年代**：
+        * **对象生命周期差异**：大多数对象在创建后很快就会变得不可达（短命对象），只有少量对象会存活很长时间（长命对象）。分代收集可以针对不同生命周期的对象采用不同的回收策略，提高效率。
+        * **回收效率**：新生代对象密度高（很多是垃圾），适合使用复制算法（Copying），速度快。老年代对象密度低（大部分是活对象），适合使用标记-清除（Mark-Sweep）或标记-整理（Mark-Compact）算法，减少内存浪费。
+        * **减少Full GC频率**：将长命对象移到老年代，可以减少它们被频繁扫描和回收的开销，降低Full GC的频率。
+    * **为什么新生代分Eden和Survivor**：
+        * **复制算法的实现**：新生代主要使用复制算法。将新生代分为Eden和两块大小相同的Survivor空间，每次分配对象时都在Eden区进行。当Eden区满时触发Minor GC，将Eden和一块Survivor中存活的对象复制到另一块空的Survivor中，并清理掉Eden和原Survivor。存活的对象年龄增加，达到一定年龄（默认15，由 `-XX:MaxTenuringThreshold` 控制）的对象会被晋升到老年代。
+        * **空间效率**：任何时候都保证有一块Survivor是空的，作为下次GC时的复制目标，避免了频繁的内存分配和整理。理论上只有10%的空间被“浪费”（因为Survivor区占新生代的1/10），但能高效处理大量短命对象的创建和回收。
+        * **对象年龄管理**：Survivor区可以用来记录对象的存活时间，为对象晋升到老年代提供依据。
 7. JVM 出现 fullGC 很频繁，怎么去线上排查问题？
+   答：排查频繁Full GC的步骤：
+    * **收集GC日志**：确保JVM开启了GC日志功能，例如：`-Xlog:gc*=info:file=/path/to/gc.log:time,uptime,level,tags`。日志文件记录了每次GC的类型、耗时、堆内存变化等信息。
+    * **分析GC日志**：使用工具（如 `jcmd <pid> GC.print_heap_at_gc`, `jstat -gcutil <pid>`, 或专门的日志分析工具如GCEasy, GCViewer）分析日志。
+        * 查看Full GC的触发原因：是老年代空间不足？永久代/元空间空间不足？还是System.gc()被调用？或是CMS的Concurrent Mode Failure（并发模式失败）或Promotion Failed（晋升失败）？
+        * 观察老年代、新生代、永久代/元空间的使用趋势，判断是哪个区域导致的问题。
+        * 计算Full GC的平均间隔时间和耗时，评估影响。
+    * **生成Heap Dump**：在Full GC发生时或之后，使用 `-XX:+HeapDumpOnOutOfMemoryError` 或手动使用 `jmap -dump:live,format=b,file=heap.hprof <pid>` 生成堆转储快照。
+    * **分析Heap Dump**：使用MAT（Eclipse Memory Analyzer Tool）、VisualVM、JProfiler等工具加载Heap Dump。
+        * 查找内存泄漏：通过Dominator Tree或 Leak Suspects 报告，找出占用内存最多的对象及其引用链，判断是否有对象本应被回收但被长期持有引用。
+        * 检查大对象：查找占用空间特别大的对象，判断是否是正常业务需求还是异常产生。
+        * 检查线程栈：有时线程长时间持有锁或处于某种状态也会间接导致内存问题。
+    * **检查代码和配置**：
+        * 代码层面：检查是否有静态集合类长期持有对象引用、大对象创建后未释放、缓存机制设计不合理、线程泄漏等问题。
+        * 配置层面：检查堆内存大小（ `-Xms`, `-Xmx`）是否设置过小；老年代、新生代比例是否合理；Survivor区比例是否合适；GC算法选择是否适合当前应用场景；元空间大小（ `-XX:MetaspaceSize`, `-XX:MaxMetaspaceSize`）是否足够。
+    * **监控指标**：结合系统监控（如CPU、内存、线程数）和应用监控（如请求量、响应时间），看Full GC是否与特定操作或高峰期相关。
 8. JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代，说说你知道的几种主要的JVM参数。
+   答：
+    * **一次完整的GC流程**：通常指从Minor GC到可能触发Full GC的过程。
+        1.  **Minor GC**：在新生代空间（主要是Eden区）满时触发。GC线程会暂停用户线程（STW），扫描Eden区和From Survivor区，将存活的对象复制到To Survivor区，并清理Eden区和From Survivor区。存活对象年龄+1。如果对象年龄达到阈值，则晋升到老年代。
+        2.  **Major GC / Full GC**：通常在以下情况触发：
+            * 老年代空间不足（如新生代对象晋升导致老年代满）。
+            * 永久代/元空间空间不足。
+            * System.gc()被调用（建议，非强制）。
+            * CMS GC中的Concurrent Mode Failure或Promotion Failed。
+            * 统计得到的Minor GC晋升到老年代的平均大小大于老年代的剩余空间。
+              Full GC会扫描整个堆（新生代和老年代），并可能进行整理（取决于GC算法），耗时较长，会导致较长时间的STW。
+    * **对象如何晋升到老年代**：
+        * **年龄阈值**：在Survivor区中，对象每熬过一次Minor GC，年龄就加1。当年龄达到一定值（默认15，由 `-XX:MaxTenuringThreshold` 设置），在下次Minor GC时就会被复制到老年代。
+        * **大对象直接进入老年代**：对于一些很大的对象（超过 `-XX:PretenureSizeThreshold` 设置的大小），为了避免在Survivor区之间复制带来的性能开销，会直接在新生代GC时分配到老年代。
+        * **动态年龄判定**：JVM并不总是严格按照年龄阈值。它会统计Survivor区中各个年龄对象占用的总大小，如果某个年龄的所有对象的总大小大于Survivor区的一半，那么大于或等于该年龄的所有对象将直接进入老年代，即使它们的年龄还没达到阈值。
+    * **主要的JVM参数**：
+        * **堆内存相关**：
+            * `-Xms<size>`：初始堆大小。
+            * `-Xmx<size>`：最大堆大小。
+            * `-Xmn<size>`：新生代大小（通常老年代大小 = MaxHeapSize - NewSize）。
+            * `-XX:NewRatio=<n>`：老年代/新生代的比例（默认2，即老年代:新生代=2:1）。
+            * `-XX:SurvivorRatio=<n>`：Eden/Survivor的比例（默认8，即Eden:Survivor=8:1）。
+            * `-XX:MaxTenuringThreshold=<n>`：对象晋升老年代的最大年龄（默认15）。
+            * `-XX:PretenureSizeThreshold=<size>`：大于此大小的对象直接分配在老年代（仅对Serial和Parallel Scavenge GC有效）。
+        * **GC相关**：
+            * `-XX:+UseSerialGC`：使用Serial GC。
+            * `-XX:+UseParNewGC`：使用ParNew GC（新生代并行）。
+            * `-XX:+UseParallelGC` / `-XX:+UseParallelOldGC`：使用Parallel Scavenge / Parallel Old GC。
+            * `-XX:+UseConcMarkSweepGC`：使用CMS GC。
+            * `-XX:+UseG1GC`：使用G1 GC。
+            * `-XX:MaxGCPauseMillis=<time>`：G1 GC的目标最大停顿时间（毫秒）。
+            * `-XX:ParallelGCThreads=<n>`：并行GC线程数。
+            * `-XX:ConcGCThreads=<n>`：并发GC线程数（用于CMS、G1等并发GC）。
+        * **元空间/永久代相关**：
+            * `-XX:PermSize=<size>` / `-XX:MaxPermSize=<size>`：永久代大小（JDK 7及之前）。
+            * `-XX:MetaspaceSize=<size>` / `-XX:MaxMetaspaceSize=<size>`：元空间大小（JDK 8及之后）。
+        * **其他**：
+            * `-XX:+PrintGCDetails`：打印详细的GC日志。
+            * `-Xlog:gc*=info`：JDK 9+推荐的GC日志方式。
+            * `-XX:+HeapDumpOnOutOfMemoryError`：OOM时生成Heap Dump。
+            * `-XX:HeapDumpPath=<path>`：指定Heap Dump文件路径。
+            * `-Xss<size>`：设置线程栈大小。
 9. 垃圾回收算法的实现原理。
+   答：主要的垃圾回收算法及其原理：
+    * **标记-清除（Mark-Sweep）**：
+        * **原理**：分为两个阶段。第一阶段“标记”，从GC Roots开始遍历对象图，标记所有可达对象。第二阶段“清除”，遍历整个堆，回收所有未被标记的对象所占用的空间。
+        * **优点**：实现简单，不需要移动对象。
+        * **缺点**：效率不高（两次遍历），会产生大量内存碎片，可能导致后续分配大对象时需要触发Full GC。
+    * **标记-整理（Mark-Compact）**：
+        * **原理**：也是分为两个阶段。第一阶段“标记”与Mark-Sweep相同。第二阶段“整理”，将所有存活的对象向内存区域的一端移动，然后清理掉边界以外的内存。
+        * **优点**：解决了内存碎片问题。
+        * **缺点**：移动对象成本高（需要更新所有指向这些对象的引用），暂停时间长。
+    * **复制（Copying）**：
+        * **原理**：将内存分为两块大小相等的区域（如Eden和Survivor）。每次只使用其中一块（Eden + 一块Survivor）。当发生GC时，将存活的对象从当前使用的区域复制到另一块空闲区域，并清理掉原区域。
+        * **优点**：实现简单，效率高（只复制存活对象，且分配内存是O(1)操作），不会产生内存碎片。
+        * **缺点**：空间利用率低（只有一半空间可用），对于存活对象多的场景（如老年代）不适用。
+    * **分代收集（Generational Collection）**：不是一种具体的算法，而是一种策略。基于对象生命周期差异的假设，将堆分为新生代和老年代。新生代使用复制算法（对象“短命”，复制成本低），老年代使用标记-清除或标记-整理算法（对象“长命”，移动成本高但碎片问题更突出）。
+    * **增量收集（Incremental Collection）**：将一次GC任务分解为多个小步，每次执行一小步GC，然后让用户线程运行一段时间，再执行下一小步。目的是减少单次GC的停顿时间，但可能会增加总GC时间和复杂性。
+    * **并发收集（Concurrent Collection）**：利用GC线程和用户线程并发执行的部分，减少STW时间。例如CMS和G1的并发标记、并发清除阶段。但并发阶段可能会增加CPU开销，且存在“浮动垃圾”问题。
 10. JVM内存模型的相关知识了解多少，比如重排序，内存屏障，happen-before，主内存，工作内存等。
+    答：JVM内存模型（Java Memory Model, JMM）是用于屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果的规范。它关注的是多线程之间的内存可见性和指令重排序问题。
+    * **主内存（Main Memory）和工作内存（Working Memory）**：JMM规定，所有的变量都存储在主内存中（可以理解为物理内存），每条线程有自己的工作内存（可以理解为CPU缓存或寄存器）。线程对变量的操作（读取、赋值等）都必须在工作内存中进行。线程间变量值的传递需要通过主内存来完成。这解释了为什么在多线程环境下，不恰当的共享变量访问会导致数据不一致。
+    * **重排序（Reordering）**：为了提高性能，编译器优化和处理器可能会对指令的执行顺序进行重排序，只要不违反数据依赖性。重排序包括编译器重排序和处理器重排序。
+        * **编译器重排序**：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
+        * **处理器重排序**：现代处理器采用流水线、乱序执行等技术，也可能导致指令的执行顺序与程序代码的顺序不同。
+    * **内存屏障（Memory Barrier / Fences）**：也叫栅栏指令。是一种CPU或编译器指令，用于控制特定操作的执行顺序，可以用来禁止特定类型的处理器重排序和编译器重排序。主要有Load Barrier（读屏障）和Store Barrier（写屏障）。在Java中，`volatile`变量的读写、锁的释放/获取等操作都会隐含地使用内存屏障来保证可见性和有序性。
+    * **happens-before原则**：JMM提供了一系列规则（happens-before rules），用来判断多线程之间操作 visibility（可见性）和 ordering（有序性）。如果操作A happens-before 操作B，那么A的执行结果对B可见，并且A一定会发生在B之前（虽然不一定是时间上的先后，可能被重排序）。主要规则包括：
+        * 程序顺序规则：一个线程内，按照代码顺序，写在前面的操作 happens-before 后面的操作。
+        * 锁规则：解锁 happens-before 后面对同一个锁的加锁。
+        * volatile变量规则：对一个 volatile 变量的写操作 happens-before 后面对这个变量的读操作。
+        * 传递性：如果A happens-before B，且 B happens-before C，那么 A happens-before C。
+        * 线程启动规则：线程的 start() 方法 happens-before 该线程的每一个动作。
+        * 线程中断规则：对线程 interrupt() 的调用 happens-before 被中断线程的代码检测到中断事件的发生。
+        * 线程终结规则：线程中的所有操作 happens-before 线程的终止检测。
+        * 对象终结规则：一个对象的构造函数执行结束 happens-before 该对象的 finalize() 方法开始执行。
+        * 传递性（再次强调）：如果A happens-before B，且 B happens-before C，那么 A happens-before C。
+          了解这些概念有助于理解多线程编程中的并发问题，如竞态条件、死锁等，以及如何使用 `volatile`, `synchronized`, `final`, `Lock` 等机制来保证线程安全。
 11. 说一下Java对象的创建过程
+    答：Java对象的创建过程大致如下：
+    1.  **类加载检查**：当JVM遇到一条new指令时，首先检查这个指令的参数能否在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，则执行相应的类加载过程。
+    2.  **分配内存**：为对象分配内存。对象所需内存大小在类加载完成后便可确定。分配方式有“指针碰撞”（Bump the Pointer）和“空闲列表”（Free List）两种。
+        * 指针碰撞：如果堆内存规整（没有内存碎片），即已使用的内存和空闲内存通过一个指针分界，分配内存就是将指针向空闲区域移动与对象大小相等的距离。
+        * 空闲列表：如果堆内存不规整，JVM维护一个列表记录哪些内存块是可用的，分配时从列表中找到一块足够大的空间分配给对象，并更新列表。
+          选择哪种方式取决于垃圾收集器是否带有空间整理（Compact）功能。Serial, Parallel Scavenge等带压缩的收集器采用指针碰撞；CMS等基于标记-清除算法的收集器通常采用空闲列表。
+          **并发问题**：多线程环境下分配内存可能产生冲突。解决方法有：
+            * **CAS（Compare-And-Swap）+ 失败重试**：多个线程尝试更新指针，通过CAS保证原子性，失败则重试。
+            * **TLAB（Thread Local Allocation Buffer）**：为每个线程分配一小块私有内存，线程先从TLAB中分配内存，只有TLAB用完才需要同步去主分配区域申请，大大减少锁竞争。
+    3.  **初始化零值**：内存分配完成后，JVM会将分配到的内存（不包括对象头）按默认值进行初始化零值（所有基本类型为0或false，引用类型为null）。这保证了对象实例字段在Java代码中可以不赋初值就直接使用，不会出现非预期的默认值。
+    4.  **设置对象头**：JVM会在对象头（Header）中存储一些元数据信息，如：
+        * 对象所属的类元数据指针（指向方法区或元空间中的类信息）。
+        * 对象的哈希码（如果计算过）。
+        * GC分代年龄（对象年龄）。
+        * 锁状态标志、偏向线程ID、偏向时间戳等（与锁相关）。
+        * 是否为偏向锁、轻量级锁等。
+    5.  **执行`<init>`方法（即构造函数）**：在内存分配、零值初始化和对象头设置完成后，JVM会为对象分配一个实例方法区，并执行类的构造函数（`<init>`方法），即用户代码中定义的构造方法。构造函数负责为对象初始化非零值，并执行其他初始化逻辑。如果构造函数中调用了父类的构造方法（`super()`），则先执行父类的构造方法。
 12. 你们线上应用的JVM参数配置了哪些。
+    答：这是一个开放性问题，具体配置会根据应用类型（如Web服务、批处理、内存数据库等）、硬件资源、并发量、历史性能数据等因素有很大差异。以下是一些常见的线上JVM参数配置方向和例子，具体值需要根据实际情况调整：
+    * **堆内存设置**：
+        * `-Xms<size>` 和 `-Xmx<size>`：通常设置相同的值，避免运行时动态扩容/缩容带来的性能开销。例如：`-Xms4g -Xmx4g`。
+        * `-Xmn<size>`：新生代大小，对于年轻代回收频繁的应用，可以适当调大，减少Full GC。例如：`-Xmn1g`。
+        * `-XX:NewRatio=<n>`：老年代与新生代的比例，默认2，可以根据应用对象生命周期调整。
+        * `-XX:SurvivorRatio=<n>`：Eden与单个Survivor区的比例，默认8。
+    * **GC收集器选择**：
+        * `-XX:+UseG1GC`：对于大内存（>4G）服务器应用，推荐使用G1 GC，追求可预测的停顿时间。
+        * `-XX:+UseParallelGC` 或 `-XX:+UseParallelOldGC`：对于追求高吞吐量的批处理或后台任务，可以使用Parallel GC。
+        * `-XX:+UseConcMarkSweepGC`：对于老版本应用或特定场景，可能还在使用CMS，但需要配合相关参数调优。
+    * **GC调优相关**：
+        * `-XX:MaxGCPauseMillis=<time>`：G1 GC的目标最大停顿时间（毫秒），G1会据此调整Region大小和回收策略。
+        * `-XX:ParallelGCThreads=<n>`：并行GC线程数，通常设置为等于或小于CPU核心数。
+        * `-XX:ConcGCThreads=<n>`：并发GC线程数，用于并发标记、清理阶段。
+        * `-XX:G1HeapRegionSize=<size>`：G1中Region的大小，影响GC效率和停顿时间。
+        * `-XX:PretenureSizeThreshold=<size>`：大对象直接进入老年代的大小阈值。
+        * `-XX:MaxTenuringThreshold=<n>`：对象晋升老年代的最大年龄。
+    * **元空间设置（JDK 8+）**：
+        * `-XX:MetaspaceSize=<size>`：元空间初始大小，达到此值会触发Full GC。
+        * `-XX:MaxMetaspaceSize=<size>`：元空间最大大小，防止元空间无限增长。
+    * **其他**：
+        * `-XX:+UseCompressedOops`：使用压缩普通对象指针，节省内存。
+        * `-XX:+UseStringDeduplication`：启用字符串去重，减少字符串常量内存占用（G1特有）。
+        * `-XX:+PrintGC` 或 `-Xlog:gc`：打印GC日志。
+        * `-XX:+HeapDumpOnOutOfMemoryError`：OOM时生成Heap Dump。
+        * `-Djava.awt.headless=true`：如果是纯后台服务，可以设置为无头模式。
+          **重要提示**：以上仅为示例，实际线上配置需要结合具体应用进行压测、监控和调优。没有绝对最优的配置，只有最适合当前应用和环境的配置。
 13. G1和cms区别。
+    答：G1（Garbage-First）和CMS（Concurrent Mark Sweep）都是针对服务器的垃圾收集器，都试图减少Full GC的停顿时间，但它们在实现原理、工作方式、适用场景等方面存在显著区别：
+    * **内存布局与分代**：
+        * **CMS**：仍然基于传统的分代模型（新生代、老年代、永久代/元空间），但主要关注新生代和部分老年代（CMS只回收整个老年代或整个新生代，或者整个堆的一部分）。
+        * **G1**：不要求物理上连续的内存空间，将堆划分为多个大小相等的独立Region。每个Region可以是Eden、Survivor或Old。G1同时管理新生代和老年代，但通过Region来组织。它还有一个Humongous Region用于存储大对象。
+    * **GC目标与策略**：
+        * **CMS**：主要目标是获取最短回收停顿时间。它主要在老年代空间不足时触发，采用并发标记和并发清除策略，大部分工作不暂停用户线程。
+        * **G1**：同样追求低停顿，但更强调可预测的停顿时间（通过 `-XX:MaxGCPauseMillis` 指定）。它采用增量式、分批次、优先回收价值最大Region的策略，不一次性回收整个堆。通过跟踪Region的回收价值（回收空间大小和回收时间），优先回收那些回收后能获得较大可用空间的Region。
+    * **内存碎片处理**：
+        * **CMS**：基于“标记-清除”算法，会产生内存碎片。碎片过多时，即使老年代还有空间，也可能因为无法找到足够连续的内存块而触发Full GC（Concurrent Mode Failure），此时会暂停用户线程进行碎片整理，导致停顿时间可能很长。
+        * **G1**：在回收时（Cleanup阶段）会进行Region间的对象复制和整理，从而有效避免了内存碎片问题。虽然G1也进行对象复制，但其设计使得这种复制成本相对可控。
+    * **并发处理**：
+        * **CMS**：并发标记和并发清除阶段需要用户线程配合，即不能修改已标记对象的引用。这限制了并发效率，并且存在“浮动垃圾”（并发标记后新产生的垃圾，只能下次GC回收）。
+        * **G1**：并发标记阶段与用户线程并发，并发清除阶段（实际是并发复制）也与用户线程并发。G1通过更精确的并发标记和Region管理，能更好地处理并发过程中的对象引用变化，浮动垃圾问题相对较好。
+    * **适用场景**：
+        * **CMS**：适合老年代对象存活率不高，或者存活对象只占老年代一小部分，且对停顿时间要求严格的应用。
+        * **G1**：适合大内存（>4G）、多核CPU的服务器应用，对停顿时间有要求，且对象大小分布可能不均的场景。它更通用，并且能随着堆大小增加而扩展。
+    * **其他**：
+        * **并发模式失败（Concurrent Mode Failure）**：CMS中较常见，会导致STW进行碎片整理。
+        * **Promotion Failed**：CMS中，新生代对象晋升到老年代时，老年代空间不足，会导致STW进行Full GC。
+        * **Humongous Region**：G1特有的，用于存放大对象，如果一个大对象超过了一个Region的大小，会被视为巨型对象，占用多个连续的Humongous Region。
+          简单总结：CMS更专注于老年代，通过并发减少停顿，但碎片问题突出；G1更整体地管理堆，通过Region和优先级列表实现更可控、可预测的低停顿，并解决了碎片问题，适用性更广。
 14. 怎么打出线程栈信息。
-15. 说一下类加载的执行过程
+    答：在Java中，可以通过以下几种方式获取线程栈信息（Thread Dump）：
+    * **使用JDK自带的工具**：
+        * `jstack <pid>`：这是最常用的命令行工具。`<pid>`是目标Java进程的进程ID。执行该命令会打印出该JVM中所有线程的当前状态和调用栈信息。可以定期执行（如每5秒执行一次，连续执行几次）来观察线程状态变化，有助于定位死锁或线程阻塞问题。
+        * `jcmd <pid> Thread.print`：JDK 1.7及以上版本提供。效果与 `jstack` 类似，输出格式可能略有不同。
+        * `jconsole`：图形化工具，连接到JVM后，在“线程”选项卡中可以查看所有线程及其状态，还可以导出线程栈信息。
+        * `VisualVM`：图形化工具，功能类似jconsole，也能查看和导
+15. 说一下类加载的执行过程。
+    答：Java类的加载过程主要包含以下五个阶段，通常遵循双亲委派模型：
+    1.  **加载（Loading）**：查找并读取类的二进制字节流（如.class文件、网络、动态生成等），将其转换为JVM内部的`java.lang.Class`对象实例。这个阶段主要是类加载器根据类的全限定名找到对应的字节码，并读取这些字节码。
+    2.  **验证（Verification）**：确保加载的类文件符合JVM规范，不会造成安全风险。这包括文件格式验证、元数据验证、字节码验证和符号引用验证。这个阶段比较耗时，但可以保证类的安全性和正确性。
+    3.  **准备（Preparation）**：为类变量（静态变量）分配内存，并设置类变量指定的初始值（通常是零值，如int为0，boolean为false，引用类型为null）。注意：这里不包含代码中显示赋值的值，例如 `public static int value = 123;` 在准备阶段value的值是0，赋值为123是在初始化阶段完成的。
+    4.  **解析（Resolution）**：将类、接口、字段和方法的符号引用转换为直接引用。符号引用是编译时生成的标记，直接引用是指向内存中目标地址的指针或偏移量。这个过程可能发生在初始化之前或之后，取决于具体实现。
+    5.  **初始化（Initialization）**：这是类加载的最后阶段，真正执行类中定义的Java代码（静态初始化块、静态变量赋值语句）。在这个阶段，静态变量会被赋予程序员指定的初始值，静态代码块会被执行。这个阶段是线程安全的，JVM会保证一个类只被初始化一次。
 16. JVM垃圾回收机制，何时触发MinorGC等操作呢？
-17. ZGC 垃圾收集器，了解过吗
+    答：JVM的垃圾回收机制旨在自动回收不再被程序使用的内存，主要目标是减少内存泄漏和手动内存管理的复杂性。
+    *   **何时触发MinorGC（新生代GC）**：
+        MinorGC主要发生在新生代内存空间不足时。常见的触发条件包括：
+        1.  Eden区空间用尽：当新创建的对象无法在Eden区分配内存时，会触发MinorGC，将Eden区和From Survivor区中还存活的对象复制到To Survivor区，并清空Eden区和From Survivor区。存活对象年龄+1。
+        2.  达到一定比例的阈值：有些GC算法（如Parallel Scavenge）会根据吞吐量目标或回收效率来触发MinorGC，不一定等到Eden区完全填满。
+        3.  System.gc()调用：虽然不直接保证只触发MinorGC，但在某些情况下可能导致MinorGC。
+    *   **何时触发MajorGC / FullGC**：
+        MajorGC通常指老年代垃圾回收，而FullGC是包括新生代、老年代、元空间（或永久代）在内的完整垃圾回收，会暂停所有用户线程（STW - Stop-The-World）。触发FullGC的条件通常更复杂，包括：
+        1.  **老年代空间不足**：当MinorGC后，有大量对象（通常超过某个阈值，如Parallel GC的`-XX:MaxTenuringThreshold`）晋升到老年代，导致老年代空间不足时。
+        2.  **元空间/永久代空间不足**：在老版本JVM（使用永久代）或新版本JVM（使用元空间）中，加载的类信息等元数据占用的空间超过设定值时。
+        3.  **系统调用System.gc()**：强烈建议JVM执行FullGC（具体行为依赖JVM实现，但通常是这样）。
+        4.  **MinorGC时空间分配担保失败**：在执行MinorGC前，JVM会检查老年代剩余空间是否足够存放本次MinorGC预期晋升的对象。如果不够，为了保证内存安全，会直接触发FullGC来腾出老年代空间。
+        5.  **元空间/永久代垃圾回收**：虽然不频繁，但在元空间/永久代空间紧张时，也会进行垃圾回收以释放不再使用的类加载器及其加载的类信息。
+17. ZGC 垃圾收集器，了解过吗？
+    答：是的，ZGC（Z Garbage Collector）是Oracle（后来成为OpenJDK的一部分）开发的一种新型低延迟垃圾收集器，旨在实现极低的停顿时间（通常在几毫秒内），同时支持非常大的堆内存（TB级别）。
+    *   **原理**：
+        ZGC的核心思想是**并发标记**和**并发整理**，尽可能减少STW（Stop-The-World）的时间。
+        1.  **颜色指针（Colored Pointers）**：这是ZGC的关键创新。它利用现代64位CPU的指针空间，将指针的低几位用于存储对象的状态信息（如是否存活、属于哪个分代、是否被重定位等）。这使得标记和重定位操作可以在不扫描整个堆的情况下，通过指针本身的状态进行判断和修改。
+        2.  **读屏障（Read Barriers）**：在程序读取对象引用时插入一个轻量级的屏障代码。这个屏障用于在并发整理过程中，如果读取到的引用指向了一个正在被移动的对象，则将其更新为新的地址。这保证了程序访问到的对象地址始终是有效的。
+        3.  **并发处理**：ZGC的标记、转移（Relocation）等主要阶段都是并发执行的，只有很短的初始标记和最终重定位阶段会STW。
+    *   **流程**：
+        1.  **并发标记（Concurrent Mark）**：遍历所有GC Roots，标记所有可达对象。这个过程与应用线程并发执行。
+        2.  **并发预备重定位（Concurrent Prepare for Relocation）**：为每个需要重定位的内存区域（Region）计算重定位集。
+        3.  **并发重定位（Concurrent Relocation）**：逐个处理重定位集。将存活对象从旧地址复制到新的连续内存空间，并更新颜色指针中的地址信息。这个过程也是并发的，读屏障负责处理应用线程在重定位过程中访问旧地址的情况。
+        4.  **并发重定位列表清理（Concurrent Relocation List Cleanup）**：清理重定位过程中的临时数据。
+    *   **优缺点**：
+        *   **优点**：
+            *   极低的停顿时间（通常 < 10ms），且停顿时间基本不随堆大小或存活对象数量增加而显著增长。
+            *   支持超大堆内存（TB级）。
+            *   高吞吐量（相对于停顿时间而言）。
+        *   **缺点**：
+            *   相对于CMS或G1，ZGC需要更多的CPU资源（尤其是核心数）来支持并发处理。
+            *   内存占用略高（由于颜色指针和内存区域管理等开销）。
+            *   较新的技术，可能在某些特定场景或旧硬件上的表现不如成熟的老牌收集器。
 18. 对象的访问定位有哪两种方式?
+    答：Java程序通过栈上的reference（引用）类型数据来操作堆上的具体对象。JVM规范中定义了两种主流的对象访问定位方式：
+    1.  **句柄池方式（Handle Pool）**：
+        *   **结构**：堆内存中划分出一块区域作为句柄池（Handle Pool）。每个对象在堆中分配时，会在句柄池中分配一个对应的句柄。
+        *   **句柄内容**：句柄通常包含两部分：对象实例数据在堆中的实际地址（`instance data address`）和对象类型数据（如方法、字段信息等）的地址（`metadata address`）。
+        *   **引用内容**：栈上的reference变量存储的是这个句柄的地址。
+        *   **访问过程**：要访问对象实例数据时，需要先通过reference找到句柄，再通过句柄找到实际的对象数据地址。要访问对象类型数据时，通过reference找到句柄，再通过句柄找到元数据地址。
+        *   **优点**：reference本身是稳定的，对象实例数据或类型数据发生移动（如GC整理）时，只需要改变句柄中的地址，而reference无需修改。
+        *   **缺点**：访问对象需要两次内存间接访问（reference -> handle -> object），效率相对较低。
+    2.  **直接指针方式（Direct Pointer / Inline Pointer）**：
+        *   **结构**：对象在堆中分配时，其内存布局中会包含类型指针（指向对象对应的类元数据）。
+        *   **引用内容**：栈上的reference变量直接存储的是对象实例数据在堆中的起始地址。
+        *   **访问过程**：通过reference可以直接定位到对象实例数据。访问类型数据时，通过对象实例数据地址加上一个固定的偏移量（由JVM内部约定）找到类型指针，再通过类型指针找到元数据。
+        *   **优点**：访问对象只需一次内存间接访问（reference -> object），效率更高。节省了句柄池的空间。
+        *   **缺点**：当对象被移动（如GC整理）时，reference中的地址需要被更新，这通常需要STW（Stop-The-World）来保证一致性。
+    *   **现状**：现代HotSpot JVM主要采用**直接指针**方式，因为它在大多数场景下性能更好。句柄池方式在一些较早的JVM实现或特定场景下可能存在。
 19. 说一下 jvm 调优的工具？
+    答：JVM调优过程中会用到多种工具来监控、诊断和优化JVM性能，主要分为JDK自带工具和第三方商业/开源工具：
+    *   **JDK自带工具**：
+        1.  **jps (Java Process Status)**：查看当前主机上所有Java进程的进程ID（PID）和主类名，是使用其他JDK工具的第一步。
+        2.  **jstat (Java Virtual Machine statistics monitoring tool)**：监控各种JVM内部状态，特别是垃圾收集信息。常用选项如 `jstat -gcutil <pid> <interval> <count>` 查看堆内存使用率和GC统计。
+        3.  **jstack (Java Stack Trace)**：生成线程快照（Thread Dump），用于分析线程状态、死锁等问题（已在问题14中详细说明）。
+        4.  **jmap (Java Memory Map)**：
+            *   `jmap -heap <pid>`：查看堆内存整体情况，包括堆大小、使用量、分代情况等。
+            *   `jmap -histo <pid>`：查看堆上对象实例数量和占用大小统计（按类排序）。
+            *   `jmap -dump:live,format=b,file=<filename.hprof> <pid>`：生成堆转储快照（Heap Dump），是分析内存泄漏的关键，`live`参数表示只包含存活对象。
+        5.  **jinfo (Configuration Info for Java)**：查看和动态修改JVM的运行时参数。`jinfo -flags <pid>` 查看所有JVM参数，`jinfo -sysprops <pid>` 查看系统属性。
+        6.  **jhat (Java Heap Analysis Tool)**：用于分析由jmap生成的堆转储文件（.hprof）。已逐渐被弃用，推荐使用VisualVM或Eclipse MAT等更强大的工具。
+        7.  **VisualVM (jvisualvm)**：集成了jstat、jstack、jmap的部分功能，提供图形化界面，可以监控CPU、内存、线程、GC情况，查看堆转储、线程快照等，非常实用。
+        8.  **JConsole**：基于JMX的图形化监控工具，可以连接JVM，查看内存、线程、类加载、GC等详细信息，并支持MBean操作。
+        9.  **Arthas**：阿尔萨斯，是阿里开源的在线诊断工具，无需修改代码或重启应用即可对线上Java程序进行诊断，支持线程分析、类文件查看、方法执行监控、JVM信息查看等。
+    *   **第三方工具**：
+        1.  **Eclipse Memory Analyzer (MAT)**：强大的堆转储分析工具，特别擅长分析内存泄漏，提供 Leak Suspects 报告，可以查找占用内存最多的对象（DOM - Dominator Object Map）。
+        2.  **YourKit Java Profiler / JProfiler**：商业级Profiler，提供优秀的CPU和内存分析功能，支持抽样和仪器化分析，可以录制方法调用、分析内存分配路径等，功能非常全面。
+        3.  **GCViewer / GCLogAnalyzer**：专门用于解析和分析GC日志的工具，可以将GC日志可视化，分析GC频率、停顿时间、吞吐量等指标。
+        4.  **Prometheus + Grafana + JMX Exporter**：通过JMX Exporter将JVM的JMX指标导出到Prometheus，然后在Grafana中进行可视化监控和告警。
 20. 对象什么时候会进入老年代？
+    答：对象从新生代晋升到老年代（Tenuring）通常发生在以下几种情况：
+    1.  **达到最大年龄阈值**：这是最常见的情况。每个对象在新生代中经历一次MinorGC存活下来，其年龄（Age）就加1。当对象的年龄达到JVM参数 `-XX:MaxTenuringThreshold` 设置的最大值时，在下一次MinorGC时，这些达到最大年龄的对象会被直接复制到老年代。
+    2.  **Survivor空间不足**：在进行MinorGC时，存活下来的对象需要被复制到To Survivor区。如果To Survivor区剩余空间不足以容纳所有存活对象，那么年龄较大的对象（即使没有达到 `MaxTenuringThreshold`）会直接被晋升到老年代，以腾出Survivor空间给年轻的对象。
+    3.  **大对象直接进入老年代（Eden区分配失败）**：对于一些体积较大的对象（可以通过 `-XX:PretenureSizeThreshold` 参数设置阈值，单位字节），为了避免在Eden区和Survivor区之间发生多次复制移动的开销，JVM可以选择让它们在分配时就直接进入老年代。这个参数只对Serial、ParNew等复制算法有效，对Parallel Scavenge等不一定适用。
+    4.  **动态年龄判定**：在某些GC算法（如Parallel Scavenge）中，即使没有达到 `MaxTenuringThreshold`，如果Survivor区中相同年龄的所有对象的总大小大于Survivor空间的一半，那么年龄大于或等于该年龄的对象也会直接进入老年代，目的是为了尽快回收Survivor空间。
 21. 内存泄漏和内存溢出区别？
+    答：内存泄漏（Memory Leak）和内存溢出（Memory Overflow）是两种不同的内存问题，但都可能导致程序性能下降甚至崩溃。
+    *   **内存泄漏（Memory Leak）**：
+        *   **定义**：程序在申请内存后，在使用完毕后没有正确释放，导致这部分内存无法被再次利用，持续累积。
+        *   **原因**：通常是编程错误，比如静态集合类（如HashMap, ArrayList）长期持有对象引用；未关闭的IO流、数据库连接、网络连接等；代码逻辑错误导致引用未被清除等。
+        *   **表现**：随着程序运行时间增长，可用内存越来越少，可能导致后续内存分配失败，最终引发内存溢出。程序运行速度变慢，GC频率增加，GC时间变长。
+        *   **后果**：长期运行的应用程序可能会因为内存泄漏而耗尽内存，即使总内存需求并未超过物理内存或堆大小。
+    *   **内存溢出（Memory Overflow）**：
+        *   **定义**：程序申请的内存超过了系统所能提供的最大内存限制（如JVM的堆内存上限 `-Xmx`）。
+        *   **原因**：
+            *   程序本身需要处理的数据量过大，超出了分配的内存。
+            *   发生了内存泄漏，累积的对象占用了过多内存。
+            *   单个对象过大（如超大字符串、超大数组、超大对象图），导致无法在剩余内存中分配。
+            *   JVM参数 `-Xmx` 设置得过小。
+        *   **表现**：程序抛出 `OutOfMemoryError` 异常，如 `java.lang.OutOfMemoryError: Java heap space`。
+        *   **后果**：通常是程序崩溃或无法继续运行。
+    *   **区别总结**：
+        *   **本质**：内存泄漏是**内存管理不当**导致内存无法回收；内存溢出是**内存需求超限**导致无法分配新内存。
+        *   **关系**：内存泄漏是导致内存溢出的常见原因之一，但内存溢出也可能由正常的、合法的大量数据请求引起（只是超出了分配限制）。
+        *   **发生时机**：内存泄漏是渐进式的，随时间累积；内存溢出可能是突然发生的（如处理一个超大请求），也可能是渐进累积到某个阈值后发生。
 22. 什么是tomcat类加载机制？
-23. 了解逃逸分析技术吗
+    答：Tomcat的类加载机制是其实现模块化、隔离性以及支持热部署/热加载的关键部分。它并非完全遵循JVM标准的双亲委派模型，而是进行了扩展和定制，形成了所谓的“Tomcat类加载器层次结构”。
+    *   **核心思想**：为了实现Web应用程序之间的隔离，以及应用与Tomcat核心、应用服务器环境之间的隔离，Tomcat定义了多个类加载器，每个加载器负责加载特定范围的类。
+    *   **主要类加载器**：
+        1.  **Bootstrap ClassLoader**：JVM自带的引导类加载器，加载`JAVA_HOME/lib`下的核心Java类库（如rt.jar）。
+        2.  **Extension ClassLoader**：加载`JAVA_HOME/lib/ext`下的扩展类库。
+        3.  **System ClassLoader (AppClassLoader)**：加载应用程序的类路径（`CLASSPATH`）下的类。Tomcat本身作为一个应用，也有一个系统类加载器来加载其核心功能类。
+        4.  **Common ClassLoader**：Tomcat特有的，用于加载Tomcat自身以及所有Web应用共享的类（如servlet-api.jar）。它位于系统类加载器和WebApp ClassLoader之间。
+        5.  **Catalina ClassLoader**：用于加载Tomcat Catalina模块（Servlet容器核心）的类，这些类对Web应用通常是不可见的，实现容器与应用的隔离。
+        6.  **Shared ClassLoader**：早期版本（Tomcat 7及之前）存在，用于加载所有Web应用共享但不属于Common层的类。在Tomcat 8及之后，其功能通常由Common ClassLoader或WebApp ClassLoader的父加载器承担。
+        7.  **WebApp ClassLoader**：每个Web应用都有一个独立的WebApp ClassLoader。这是Tomcat实现应用隔离的关键。它负责加载`WEB-INF/classes`和`WEB-INF/lib`下的类。它的加载策略是：**先尝试自己加载（实现“自举”或“孩子优先”），如果找不到，再委托给父加载器（Common/Catalina等）**。这打破了双亲委派模型，确保不同应用可以使用相同类名的不同版本，实现隔离。
+        8.  **JasperLoader**：用于加载JSP编译后生成的Servlet类。当JSP文件被修改后，旧的JasperLoader会被丢弃，创建新的JasperLoader来加载新的Servlet类，实现JSP的热重载。
+    *   **特点**：
+        *   **打破双亲委派**：主要是WebApp ClassLoader和JasperLoader，实现应用隔离和热部署。
+        *   **层次结构**：各类加载器按需加载特定目录下的类。
+        *   **隔离性**：不同Web应用之间、应用与Tomcat核心之间通过类加载器实现类库隔离。
+23. 了解逃逸分析技术吗？
+    答：是的，逃逸分析（Escape Analysis）是现代JVM（如HotSpot）中的一项重要的优化技术。
+    *   **定义**：逃逸分析是指在编译期或运行期（HotSpot主要在即时编译器 - JIT Compiler 中进行）分析对象的引用范围，判断一个对象的作用域是否会“逃逸”出当前方法、线程。
+    *   **判断标准**：
+        *   **方法逃逸**：如果对象被作为参数传递给其他方法，或者被返回给调用者，则认为发生了方法逃逸。
+        *   **线程逃逸**：如果对象被存储到堆内存（如实例变量、静态变量），或者被发布到其他线程可见的地方（如共享数据结构），则认为发生了线程逃逸。
+    *   **目的**：如果确定一个对象不会发生逃逸（即对象的作用域仅限于当前方法内，且只在当前线程内被访问），JVM就可以对这个对象进行进一步的优化。
+    *   **优化手段**：
+        1.  **栈上分配（Stack Allocation）**：如果对象不逃逸出方法，JVM可以将其分配在栈帧（Stack Frame）中，而不是堆上。方法执行完毕，栈帧弹出，对象自动回收，避免了GC压力。
+        2.  **标量替换（Scalar Replacement）**：如果对象不逃逸，且其内部字段不多，JVM可以将对象拆解为其组成的原始类型字段（标量），直接将这些字段分配在栈上或寄存器中，完全避免对象的创建和管理。
+        3.  **同步消除（Lock Elimination）**：如果确定对象上的同步锁（如`synchronized`块）不会发生竞争（因为对象不逃逸，只在当前线程使用），JVM可以消除这些同步操作，提高并发性能。
+    *   **控制参数**：
+        *   `-XX:+DoEscapeAnalysis`：启用逃逸分析（默认开启）。
+        *   `-XX:-DoEscapeAnalysis`：禁用逃逸分析。
+        *   `-XX:+PrintEscapeAnalysis`：打印逃逸分析的结果（用于调试）。
+    *   **局限性**：逃逸分析并非万能，其分析结果的准确性依赖于程序代码的复杂度和JIT编译器的分析能力。对于复杂对象或难以确定逃逸状态的情况，优化可能无法进行。
 24. 调用System.gc()会发生什么?
+    答：调用 `System.gc()` 或 `Runtime.gc()` 是一个**建议**（hint）或**请求**（request），建议JVM运行时环境执行垃圾回收。JVM**不保证**一定会立即执行GC，具体行为取决于JVM的实现和当前的运行状态。
+    *   **可能发生的情况**：
+        1.  **触发Full GC**：大多数情况下，调用 `System.gc()` 会被JVM解释为需要进行一次完整的垃圾回收（Full GC），即同时回收新生代、老年代、元空间（或永久代）的垃圾。这是因为调用者通常是在内存紧张或希望释放资源时调用，Full GC能最大程度地回收内存。
+        2.  **增加GC压力**：即使JVM不立即执行GC，这个调用本身也会增加JVM内部关于GC的判断逻辑，可能更快地触发后续的GC。
+        3.  **忽略请求**：JVM完全有权忽略这个请求，特别是在内存充足、GC压力不大或者正在执行其他关键任务时。
+    *   **注意事项**：
+        *   **不保证立即执行**：开发者不应依赖 `System.gc()` 来精确控制GC时机。
+        *   **可能产生性能开销**：如果JVM决定响应这个请求并执行Full GC，会导致显著的停顿（STW），影响程序性能。频繁调用可能对性能产生负面影响。
+        *   **通常不建议手动调用**：现代JVM的GC算法（如G1, ZGC）已经相当智能，能够根据应用程序的运行状况自动调整GC策略，手动调用 `System.gc()` 往往是多余的，甚至可能适得其反。只有在极少数特定场景下（如某些JNI操作后需要明确释放资源），才可能考虑使用。
 25. 谈谈Minor GC条件，full GC条件
+    答：这个问题与问题16有部分重叠，这里再进行梳理和补充：
+    *   **Minor GC（新生代GC）触发条件**：
+        1.  **Eden区满**：这是最核心和最直接的触发条件。当新创建的对象无法在Eden区分配内存时，Minor GC就会被触发。其目的是回收Eden区以及From Survivor区中不再存活的对象，并将存活的对象复制到To Survivor区。
+        2.  **基于GC算法的策略**：某些GC算法（如Parallel Scavenge）可能会根据目标吞吐量、回收效率等动态策略来提前触发Minor GC，不一定非得等到Eden区完全填满。
+        3.  **System.gc()调用**：虽然不保证只触发Minor GC，但在某些实现或特定情况下，也可能触发Minor GC。
+    *   **Full GC（完整GC）触发条件**：
+        Full GC是对整个堆（包括新生代、老年代）以及可能存在的元空间/永久代的完整回收，通常伴随较长的STW。触发条件更复杂，主要包括：
+        1.  **老年代空间不足**：
+            *   Minor GC后，有大量对象需要晋升到老年代，但老年代剩余空间不足以容纳这些对象。
+            *   老年代本身空间耗尽，无法分配新的大对象或数组。
+        2.  **元空间/永久代空间不足**：加载的类信息等元数据占用的空间超过了设定的上限（`-XX:MaxMetaspaceSize` 或 `-XX:MaxPermSize`）。
+        3.  **Minor GC时的空间分配担保失败（Promotion Failure）**：在进行Minor GC前，JVM会预先检查老年代剩余空间是否足够存放本次Minor GC预期晋升的对象。如果检查失败（即空间不足），为了保证内存安全，会直接触发Full GC来腾出老年代空间，然后再尝试Minor GC。
+        4.  **System.gc()调用**：强烈建议JVM执行Full GC。
+        5.  **元空间/永久代垃圾回收**：虽然不频繁，但在元空间/永久代空间紧张时，也会进行垃圾回收以释放不再使用的类加载器及其加载的类信息。
+        6.  **CMS GC的特殊情况**：在CMS垃圾收集器中，可能会因为“Concurrent Mode Failure”（并发模式失败，即并发标记阶段老年代空间不够用）、“Promotion Failure”（晋升失败）或达到“InitiatingHeapOccupancyPercent”（初始堆占用百分比）等条件触发Full GC（实际上是CMS的Remark阶段及其后的回收）。
+        7.  **G1 GC的特殊情况**：G1 GC有自己的触发Full GC的条件，例如当并发GC无法满足回收目标、堆内存使用超过阈值但无法通过并发回收满足、或者发生“Evacuation Failure”（ evacuation 失败）等。
+            总结来说，Minor GC主要关注新生代的回收，通常由Eden区满触发；而Full GC是全局性的回收，触发条件更多样，通常与老年代或元空间空间不足、系统请求或特定GC算法的失败有关。
 26. Stop The World 了解过吗？
+    答：Stop The World (STW) 是指在进行垃圾回收（GC）时，JVM会暂停所有的用户线程（应用程序线程），让GC线程能够安全、高效地执行内存回收工作。这个暂停期间，应用程序不会响应任何请求，导致服务中断。STW的时间长短是衡量GC性能的一个重要指标，时间越短，对应用程序的影响越小。不同的垃圾收集器有不同的STW策略和持续时间。例如，Serial GC和Parallel GC在大部分回收阶段都需要较长时间的STW；CMS GC试图将STW时间缩短，主要在初始标记和重新标记阶段有STW；而G1和ZGC等现代GC则致力于将STW时间控制在极短（毫秒级甚至更低）并且相对稳定。
 27. 谈谈你认识多少种OOM？如何避免OOM?
+    答：常见的OOM（OutOfMemoryError）类型包括：
+1.  `java.lang.OutOfMemoryError: Java heap space`：堆内存不足。通常是由于创建了过多对象，或者存在内存泄漏（对象不再使用但仍然被引用，无法被GC回收）。
+2.  `java.lang.OutOfMemoryError: PermGen space`（在JDK 7及之前，或使用-XX:+UseParallelOldGC时可能遇到）：方法区（永久代）内存不足。通常是由于加载了太多类（如框架、动态代理、反射等），或者常量池过大。
+3.  `java.lang.OutOfMemoryError: Metaspace`（JDK 8及之后）：元空间内存不足。元空间使用本地内存，如果加载的类信息、常量等过多，可能导致元空间溢出。
+4.  `java.lang.OutOfMemoryError: Direct buffer memory`：直接内存（Native Memory）不足。通常是由于使用了NIO（New I/O）中的ByteBuffer.allocateDirect()分配了大量直接内存，或者使用Netty等框架时未及时释放。
+5.  `java.lang.OutOfMemoryError: GC overhead limit exceeded`：GC回收效率过低。当GC花费了大量时间（默认超过98%的时间）只回收了少量内存（默认每次回收后可用内存小于2%），JVM会抛出此错误，防止程序陷入“GC-等待-再GC”的死循环。
+6.  `java.lang.OutOfMemoryError: unable to create new native thread`：无法创建新的本地线程。通常是由于创建了过多线程，或者线程栈大小设置过大，导致可用本地内存不足以创建新线程。
+    避免OOM的方法：
+1.  **监控与预警**：使用监控工具（如JConsole, VisualVM, Prometheus+Grafana）实时监控内存使用情况，设置阈值预警。
+2.  **合理设置堆内存**：根据应用实际需求，合理设置-Xms（初始堆大小）和-Xmx（最大堆大小），避免过大或过小。通常建议-Xms和-Xmx设置相同，避免动态调整带来的性能开销。
+3.  **避免内存泄漏**：仔细检查代码，确保不再使用的对象能够被GC回收。注意单例、静态集合、事件监听器、内层类等容易造成引用的代码。
+4.  **优化数据结构**：选择合适的数据结构，避免不必要的大对象或集合。
+5.  **及时释放资源**：对于不再使用的资源（如文件句柄、数据库连接、网络连接、大对象等），要及时关闭或置空。
+6.  **调整GC策略和参数**：根据应用特点（如响应时间敏感度、吞吐量要求），选择合适的垃圾收集器（如G1, ZGC）并调整相关参数（如新生代/老年代比例、 Survivor区比例、GC触发阈值等）。
+7.  **控制线程数量**：合理控制线程池大小，避免创建过多线程。
+8.  **使用直接内存时谨慎**：如果使用直接内存，注意分配和释放的时机，避免泄漏。
+9.  **代码审查与测试**：进行压力测试和内存泄漏测试，及早发现问题。
 28. 了解过JVM调优没，基本思路是什么?如何确定它们的大小呢？
+    答：了解JVM调优。基本思路通常包括：
+1.  **问题定位**：首先需要明确调优的目标，是解决性能瓶颈（如CPU占用高、响应时间长）还是解决内存问题（如OOM、GC频繁）。使用监控工具（如jstat, jstack, jmap, Arthas, VisualVM等）收集运行时数据，分析GC日志，定位问题根源（是CPU计算密集型、IO密集型，还是内存分配/回收问题）。
+2.  **选择合适的GC**：根据应用场景（高吞吐量、低延迟、内存敏感等）选择合适的垃圾收集器。例如，对延迟敏感的在线服务可能选择CMS或G1，对吞吐量要求高的批处理任务可能选择Parallel GC。
+3.  **调整堆内存大小**：设置合适的堆初始大小（-Xms）和最大大小（-Xmx）。一般原则是给应用足够的空间运行，但不要超过物理内存限制，避免频繁的内存交换（Swap）。通常建议-Xms和-Xmx设为相同值，减少动态调整的开销。
+4.  **调整内存区域比例**：设置新生代和老年代的比例（-XX:NewRatio），Eden区和两个Survivor区的比例（-XX:SurvivorRatio）。新生代大小影响Minor GC的频率和速度，老年代大小影响Full GC的频率和速度。需要根据对象生命周期特点进行调整。
+5.  **优化GC参数**：针对特定GC进行参数调优，如CMS的并发线程数、G1的Region大小、目标停顿时间等。
+6.  **代码层面优化**：优化代码逻辑，减少不必要的对象创建，避免内存泄漏，使用合适的数据结构和算法。
+7.  **持续监控与迭代**：调优不是一次性的，需要持续监控应用运行状态，根据监控结果和用户反馈，不断调整和优化参数。
+    确定堆大小（-Xmx/-Xms）的方法：
+1. **经验法则**：对于单机应用，通常建议堆大小设置为可用物理内存的50%-80%，但要确保有足够的内存留给操作系统和其他进程，并避免Swap。具体比例需要根据应用特性和服务器配置调整。
+2. **压力测试**：在模拟生产环境负载的情况下进行压力测试，观察内存使用峰值。逐步增加负载，找到内存使用量的稳定增长趋势，然后设置一个略高于峰值（如峰值+10%-20%）的堆大小作为-Xmx。同时观察GC行为，如果GC过于频繁或停顿时间过长，可能需要调整堆大小或GC参数。
+3. **公式估算**：有一些估算公式，如 `堆大小 ≈ (平均对象大小 * 对象数量) / 压缩因子`，但这通常比较粗略，需要结合实际情况调整。
+4. **监控分析**：通过长时间运行的应用监控数据，分析内存使用模式，找出内存需求的峰值和平均值，以此作为设置堆大小的参考。
+   确定新生代和老年代比例（-XX:NewRatio）及Eden/Survivor比例（-XX:SurvivorRatio）的方法：
+1. **对象生命周期分析**：分析应用中对象的生命周期。如果大部分对象是“朝生夕灭”（即生命周期很短），则可以增大新生代比例（减小NewRatio值），减少Minor GC频率。如果对象生命周期较长，则可以适当增大老年代比例。
+2. **GC日志分析**：通过分析GC日志，观察Minor GC和Full GC的频率、耗时以及晋升到老年代的对象大小。如果Minor GC过于频繁，可能新生代太小；如果Full GC频繁且主要由晋升失败引起，可能老年代太小或新生代太大导致过多对象晋升。
+3. **经验值**：默认情况下，新生代占堆的1/3（NewRatio=2），Eden区占新生代的8/10（SurvivorRatio=8）。这通常是一个不错的起点，可以根据实际情况进行调整。例如，可以尝试将新生代比例调整为40%-60%。
+4. **逐步调整**：从默认值或经验值开始，根据监控和GC日志表现，逐步调整比例，观察对GC频率、停顿时间和整体性能的影响。
 29. 淘宝热门商品信息在JVM哪个内存区域
+    答：淘宝热门商品信息，作为运行时需要处理的数据，其对象实例通常存储在JVM的**堆（Heap）**内存区域。具体来说：
+*   如果这些商品信息对象是短期存在的（例如，在某个请求处理过程中创建并很快不再使用），它们会首先分配在堆的新生代（Young Generation）的Eden区。
+*   如果这些对象存活时间稍长（例如，被放入缓存或会话中），它们会经历一次或多次Minor GC后，如果仍然存活，会被移动到新生代的Survivor区，最终可能被晋升（Promotion）到老年代（Old Generation）。
+*   与这些商品信息对象相关的类定义（如商品类、描述类等）的元数据（Method Area）会存储在**元空间（Metaspace，JDK 8及之后）**或**永久代（PermGen，JDK 7及之前）**中。
+*   如果处理商品信息时使用了线程，线程的栈帧（包括局部变量、操作数栈等）会存储在各自的**栈（Stack）**内存中。
+*   如果使用了直接内存（例如，通过NIO进行大数据传输），相关信息会存储在**本地内存（Native Memory）**中。
+    因此，商品信息本身的数据主要在**堆**中。
 30. 字节码的编译过程
+    答：Java字节码的编译过程主要分为两个阶段：
+1.  **源代码编译（编译时）**：
+    *   开发者编写`.java`源代码文件。
+    *   使用Java编译器（`javac`）将`.java`文件编译成平台无关的字节码（Bytecode），输出为`.class`文件。
+    *   这个阶段主要进行语法检查、语义分析、代码优化（如常量折叠、公共子表达式消除等），并将高级的Java语言特性转换为基于栈的指令集（即字节码）。字节码是一种中间表示，包含了方法、字段、类结构等信息，但还不能直接被底层硬件执行。
+2.  **字节码解释与即时编译（运行时）**：
+    *   当Java程序运行时，JVM加载`.class`文件。
+    *   **解释执行**：JVM中的解释器（Interpreter）逐条读取字节码指令，并将其翻译成底层操作系统和硬件能理解的机器码来执行。这种方式启动快，但执行效率相对较低。
+    *   **即时编译（Just-In-Time Compilation, JIT）**：为了提高执行效率，现代JVM（如HotSpot）会监控代码的执行情况。对于频繁执行的“热点代码”（Hotspot Code），JVM的即时编译器（如C1, C2）会将这些字节码编译成本地机器码，并缓存起来。下次执行时，直接运行编译好的本地代码，速度远快于解释执行。JIT编译会进行更激进的优化（如内联、循环展开、逃逸分析等）。
+        总结来说，字节码编译过程是从人类可读的Java源代码到JVM可执行的中间指令（字节码），再到最终由JVM解释或编译成本地机器码执行的过程。
 31. Java需要开发人员回收内存垃圾吗？
+    答：在Java中，**通常不需要**开发人员显式地回收内存垃圾。Java语言的设计初衷之一就是通过自动内存管理来解放开发人员，避免手动内存管理（如C/C++中的`malloc`/`free`或`new`/`delete`）带来的复杂性和容易出错的问题（如内存泄漏、悬垂指针等）。
+    Java的垃圾回收器（Garbage Collector, GC）会自动负责识别并回收那些不再被应用程序引用的内存对象。开发人员只需要确保：
+*   当对象不再需要时，不再持有对该对象的引用（例如，将引用变量置为`null`，或者让对象超出作用域）。
+*   避免创建不必要的对象。
+*   注意一些特殊情况，如静态集合、单例模式、内部类等可能导致的对象引用无法释放，从而引发内存泄漏。
+    虽然不需要手动回收，但开发人员需要理解GC的工作原理，以便编写出更“GC友好”的代码，并在出现内存问题时进行诊断和调优。
 32. Java中垃圾回收有什么目的？什么时候进行垃圾回收？
+    答：
+    **目的**：
+    Java中垃圾回收的主要目的包括：
+1.  **自动内存管理**：自动释放不再使用的对象所占用的内存，解放开发人员，减少内存泄漏和悬垂指针等错误。
+2.  **内存空间回收与复用**：将回收的内存空间归还给堆，供新的对象分配使用，提高内存利用率。
+3.  **防止内存溢出**：通过定期回收无用对象，避免堆内存被耗尽，从而防止`OutOfMemoryError`。
+4.  **保持内存结构合理**：某些GC算法（如分代收集）还会整理内存空间，减少内存碎片，提高对象分配效率。
+    **什么时候进行垃圾回收**：
+    垃圾回收的触发时机取决于具体的垃圾收集器及其配置，但常见的触发条件包括：
+1.  **堆内存达到一定阈值**：当Eden区（新生代的一部分）内存使用达到一定比例（通常是100%）时，会触发Minor GC（也称Young GC），回收新生代中的废弃对象。
+2.  **老年代空间不足**：当尝试将新生代中的存活对象晋升（Promote）到老年代时，如果老年代剩余空间不足以容纳这些对象，会触发Full GC（包括对新生代、老年代和元空间的全面回收）。或者，老年代本身内存使用达到一定阈值时也可能触发Full GC。
+3.  **元空间/永久代空间不足**：当加载的类信息等占用元空间/永久代的内存达到上限时，会触发针对元空间/永久代的垃圾回收。
+4.  **系统显式请求**：调用`System.gc()`或`Runtime.gc()`方法会强烈建议JVM执行Full GC，但JVM不一定立即执行，具体行为取决于JVM实现和参数设置（如`-XX:+DisableExplicitGC`可以禁用此功能）。
+5.  **GC算法特定条件**：不同的GC算法有其特定的触发条件。例如，CMS GC在并发标记阶段发现晋升失败（Concurrent Mode Failure）时会触发Remark阶段及后续的回收；G1 GC会基于Region的回收价值和期望的停顿时间来决定何时进行回收。
+    总的来说，GC主要在内存紧张或达到预设阈值时被触发，以维持JVM的稳定运行。
 33. System.gc()和Runtime.gc()会做什么事情？
+    答：`System.gc()`和`Runtime.gc()`实际上是等效的，因为`System.gc()`内部就是调用了`Runtime.getRuntime().gc()`。它们做的事情是：
+*   **发送GC请求信号**：这两个方法会向JVM发送一个**强烈建议**执行垃圾回收的信号。
+*   **不保证立即执行**：JVM收到这个信号后，**不保证**会立即启动垃圾回收过程。是否以及何时执行GC，最终由JVM根据自身策略和当前状态决定。例如，JVM可能会忽略这个请求，或者等待更合适的时机再执行。
+*   **通常触发Full GC**：当这两个方法被调用时，大多数情况下会触发一次**Full GC**，即对整个堆（包括新生代、老年代）以及可能还有元空间/永久代进行全面的垃圾回收。这是因为Minor GC通常是由Eden区满自动触发的，而手动调用`gc()`往往意味着开发者认为需要清理整个堆。
+*   **影响性能**：强制触发Full GC会导致应用程序线程暂停（Stop The World），可能引起明显的性能下降或服务中断。因此，不推荐在性能敏感的生产环境中随意调用这两个方法。
+    简而言之，它们只是给JVM一个“现在该清理垃圾了”的提示，但JVM不一定会听。
 34. 主内存与工作内存
+    答：主内存（Main Memory）和工作内存（Working Memory，也常称为线程栈或本地内存）是Java内存模型（Java Memory Model, JMM）中的两个核心概念，用于描述线程之间如何通过内存进行交互。
+*   **主内存（Main Memory）**：
+    *   属于**共享内存**区域。
+    *   所有线程共享主内存。
+    *   存储了Java实例对象、静态变量、类信息等数据。
+    *   可以理解为物理内存中，被JVM分配给该进程使用的堆（Heap）和元空间（Metaspace）/永久代（PermGen）等区域。
+*   **工作内存（Working Memory）**：
+    *   属于**线程私有**区域。
+    *   每个线程拥有自己独立的工作内存。
+    *   工作内存中存储了该线程使用到的主内存中的变量副本（包括局部变量、部分共享变量的副本）。
+    *   线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量。
+    *   可以理解为物理内存中，被分配给线程使用的栈（Stack）空间中的部分区域。
+        **交互关系**：
+        线程的工作内存与主内存之间需要通过特定的协议进行数据同步：
+*   **读（Read）**：线程从主内存中读取变量的值，并将其存储到工作内存的副本中。
+*   **写（Write）**：线程将工作内存中变量的值刷新回主内存。
+*   **载入（Load）**：将Read操作从主内存中读取的变量值，放到工作内存的变量副本中。
+*   **存储（Store）**：将工作内存中变量的值，传送到主内存中，以供Write操作使用。
+*   **使用（Use）**：线程从工作内存的变量副本中读取变量的值，并用于执行引擎。
+*   **赋值（Assign）**：线程在执行引擎中执行操作后，将结果赋值给工作内存中的变量副本。
+    JMM通过这些操作及其顺序规则（如happens-before原则）来保证多线程环境下内存访问的可见性（Visibility）和有序性（Ordering），避免因缓存不一致等问题导致的数据竞争和错误。
 35. 内存间交互操作
-36. volatile 禁止内存重排序
-37. 内存模型三大特性
-38. 谈谈先行发生原则
-39.  JVM 堆内存溢出后，其他线程是否可继续工作？
-40.  说一下JVM 常用参数有哪些？
-41.  VM 为什么使用元空间替换了永久代？
-42.  Java堆的结构是什么样子的？什么是堆中的永久代(Perm Gen space)?
-43.  JVM的永久代中会发生垃圾回收么？
-44.  什么是字节码？采用字节码的最大好处是什么？什么Java是虚拟机？
-45.  MinorGC 的过程
-46.  CPU 占用过高如何分析
-47.  Serial与Parallel GC之间的不同之处？
-48.  WeakHashMap 是怎么工作的？
-49.  解释 Java 堆空间及 GC？
-50.  你能保证 GC 执行吗？
-51.  JVM中哪个参数是用来控制线程的栈堆栈小的?
+    答：根据Java内存模型（JMM），线程的工作内存和主内存之间的交互操作主要有以下几种（这些操作是原子操作）：
+1.  **Read（读取）**：线程从主内存中读取一个变量的值。这个操作只涉及主内存，结果会用于后续的Load操作。
+2.  **Load（载入）**：线程将Read操作从主内存读取到的变量值，加载到工作内存的变量副本中。
+3.  **Use（使用）**：线程从工作内存的变量副本中读取变量的值，并将其传递给线程的执行引擎（如CPU寄存器）。这是线程实际开始操作变量的第一步。
+4.  **Assign（赋值）**：线程在执行引擎执行完操作后，将结果赋值回工作内存中的变量副本。
+5.  **Store（存储）**：线程将工作内存中变量的值，存储到一条即将发送到主内存的Write操作中。这个操作只涉及工作内存。
+6.  **Write（写）**：线程将Store操作中准备好的变量值，写入到主内存中。这是将工作内存的修改同步回主内存的步骤。
+    **操作对偶性**：
+*   Read和Load是一对操作，Read从主内存取值，Load将值放入工作内存。
+*   Store和Write是一对操作，Store准备值到Store操作中，Write将值写入主内存。
+*   Use和Assign不是严格的一对，Use是读取副本值给执行引擎，Assign是将执行结果写回副本。
+    **执行顺序**：
+*   一个变量不能被同一个线程的Read或Load操作访问两次，也不能被同一个线程的Store或Write操作访问两次，除非在其之间发生了Assign操作。
+*   一个变量在Assign操作之后，必须在其后续的Store或Write操作之前发生。
+*   Use和Assign、Read和Load、Store和Write之间可能存在重排序，但JMM通过happens-before原则等规则来限制这种重排序，以保证内存一致性。
+    这些操作是JMM描述多线程内存交互的基础，确保了在抽象层面上线程操作共享变量的正确性。实际的硬件实现可能会有缓存、流水线等机制，JMM屏蔽了这些细节，提供了统一的内存访问模型。
+
+好的，继续回答：
+36. volatile 禁止内存重排序。
+    答：`volatile` 关键字在 Java 中主要用于保证变量的可见性和禁止指令重排序。
+* **可见性**：当一个线程修改了 `volatile` 变量的值，新值会立即被写入主内存，其他线程在读取该变量时，会从主内存中重新读取，确保看到的是最新值。
+* **禁止指令重排序**：Java 内存模型（JMM）允许编译器和处理器为了优化性能而对指令进行重排序。`volatile` 变量的读操作和写操作会形成一种“内存屏障”（Memory Barrier），阻止编译器和处理器对 `volatile` 变量访问指令前后的普通读写指令进行重排序。这确保了在 `volatile` 变量之前的操作一定会在其之前执行，之后的操作一定在其之后执行，从而保证了多线程环境下某些特定代码块的执行顺序。
+37. 内存模型三大特性。
+    答：通常认为，内存模型（Memory Model）主要涉及以下三大特性，用于描述多线程环境下内存访问的行为和保证：
+1.  **原子性 (Atomicity)**：保证了每个基本操作（如读取、写入一个变量）要么完全执行，要么完全不执行，不会被其他线程打断。JMM 规定了对基本数据类型（如 `int`, `long`, `boolean` 等）的访问是原子的（除了 `long` 和 `double` 的非原子性协定，但现代 JVM 通常也保证其原子性）。`volatile`, `synchronized`, `Atomic*` 类等机制可以保证更大范围操作的原子性。
+2.  **可见性 (Visibility)**：当一个线程修改了共享变量的值，其他线程能够立即看到这个修改。如果没有同步措施，一个线程对变量的修改可能只存在于其工作内存中，其他线程可能看不到。`volatile`, `synchronized`, `final` 等关键字可以保证可见性。
+3.  **有序性 (Ordering)**：保证了程序按照代码的编写顺序执行。JMM 允许编译器和处理器进行指令重排序以提高性能，但 `volatile`, `synchronized` 等同步机制可以禁止特定情况下的重排序，保证程序在多线程环境下的执行顺序符合预期。
+38. 谈谈先行发生原则。
+    答：先行发生原则（Happens-Before Rule）是 Java 内存模型（JMM）中定义的一系列规则，用于判断多线程操作之间的内存可见性和顺序性。如果操作 A 先行发生于操作 B，那么 A 的执行结果对 B 可见，并且 A 的执行顺序排在 B 之前。即使编译器或处理器对指令进行了重排序，也必须遵守这些规则。主要的先行发生关系包括：
+1.  **程序次序规则**：一个线程内，按照代码顺序，写在前面的操作先行发生于写在后面的操作。
+2.  **锁定规则**：一个 `unlock` 操作先行发生于后面对同一个锁的 `lock` 操作。这意味着如果线程 A 解锁了某个锁，线程 B 后续获取了同一个锁，那么线程 A 在解锁前的操作都对线程 B 可见。
+3.  **`volatile` 变量规则**：对一个 `volatile` 变量的写操作先行发生于后面对这个变量的读操作。
+4.  **传递性**：如果 A 先行发生于 B，且 B 先行发生于 C，那么 A 先行发生于 C。
+5.  **线程启动规则**：`Thread` 对象的 `start()` 方法先行发生于该线程的每一个动作。
+6.  **线程中断规则**：对线程 `interrupt()` 方法的调用先行发生于被中断线程的 `interrupted()` 方法或 `isInterrupted()` 方法的返回结果。
+7.  **线程终结规则**：线程中所有的操作都先行发生于线程的 `finalize()` 方法的开始。
+8.  **对象终结规则**：一个对象的构造函数执行完成先行发生于它的 `finalize()` 方法的开始。
+9.  **传递性**：如果 A 先行发生于 B，且 B 先行发生于 C，那么 A 先行发生于 C。
+    通过这些规则，JMM 为程序员提供了一种在复杂多线程环境下，理解和保证内存一致性的方法。
+39. JVM 堆内存溢出后，其他线程是否可继续工作？
+    答：这取决于 JVM 的具体实现和配置，以及发生的是哪种类型的内存溢出。
+* **`java.lang.OutOfMemoryError: Java heap space`（堆溢出）**：如果仅仅是堆内存耗尽，而其他内存区域（如栈内存、元空间/永久代、线程本地内存等）还有空间，并且没有其他导致 JVM 终止的严重错误，那么除了尝试在堆上分配内存的线程（它会抛出 OOM 异常并可能终止）之外，其他不依赖堆内存分配的线程理论上**可以继续工作**。但是，如果堆内存是很多线程共享数据的基础，堆溢出可能导致这些线程无法正常工作或效率极低。
+* **`java.lang.OutOfMemoryError: PermGen space` 或 `java.lang.OutOfMemoryError: Metaspace`（元空间/永久代溢出）**：这通常发生在加载了过多的类，或者类元数据信息占用空间过大时。如果发生这类 OOM，整个 JVM 可能会变得不稳定，因为类加载和卸载是 JVM 核心功能的一部分。虽然某些不涉及类加载的线程可能还能短暂运行，但整体系统很可能很快崩溃或无法正常响应。
+* **`java.lang.OutOfMemoryError: Direct buffer memory`（直接内存溢出）**：这涉及到 `ByteBuffer.allocateDirect()` 分配的内存，这部分内存不由堆管理。如果发生这类 OOM，同样会终止尝试分配直接内存的线程，并可能影响整个 JVM 的稳定性。
+* **`java.lang.OutOfMemoryError: unable to create new native thread`（无法创建新线程）**：这通常不是因为堆内存不足，而是因为操作系统级别的资源限制（如 ulimit 设置、系统内存不足导致无法分配线程栈空间等）。发生这类错误时，JVM 无法创建新线程，现有线程可能会继续运行，但系统整体处理能力会大大下降。
+  总的来说，虽然某些情况下其他线程可能不会立即终止，但内存溢出通常是一个严重的错误信号，表明系统资源耗尽或存在内存泄漏等问题，最终很可能导致整个应用程序或 JVM 崩溃。
+40. 说一下JVM 常用参数有哪些？
+    答：JVM 参数种类繁多，以下是一些常用且重要的参数类别和示例：
+* **堆内存相关**：
+    * `-Xms<size>`：设置 JVM 启动时的初始堆内存大小（堆最小值）。建议设置与 `-Xmx` 相同，避免动态扩展带来的 GC 压力。
+    * `-Xmx<size>`：设置 JVM 可使用的最大堆内存大小（堆最大值）。根据应用内存需求和服务器总内存合理设置。
+    * `-Xmn<size>`：设置新生代大小。通常设置为整个堆的 1/3 到 1/2。在 G1 GC 中不直接设置，由 G1 自动管理。
+    * `-XX:NewRatio=<n>`：设置新生代与老年代的比例。默认值通常是 2，即老年代是新生代的两倍。例如 `-XX:NewRatio=2`。
+    * `-XX:SurvivorRatio=<n>`：设置 Eden 区与单个 Survivor 区的比例。默认值通常是 8，即 Eden 区大小是 Survivor 区的 8 倍。例如 `-XX:SurvivorRatio=8`。
+* **元空间/永久代相关**（JDK 8 后主要用元空间）：
+    * `-XX:MaxMetaspaceSize=<size>`：设置元空间最大大小。默认情况下，元空间大小仅受本地内存限制。
+    * `-XX:MetaspaceSize=<size>`：设置触发 Metaspace GC 的初始大小。达到此值时会发生 Full GC 来回收类元数据。
+    * （JDK 7 及之前）`-XX:MaxPermSize=<size>`：设置永久代最大大小。
+    * （JDK 7 及之前）`-XX:PermSize=<size>`：设置永久代初始大小。
+* **GC 相关**：
+    * `-XX:+UseSerialGC`：使用 Serial GC（串行回收器）。
+    * `-XX:+UseParallelGC` 或 `-XX:+UseParallelOldGC`：使用 Parallel GC（并行回收器）。
+    * `-XX:+UseConcMarkSweepGC`：使用 CMS GC（并发标记清除回收器），通常需要配合 `-XX:+UseParNewGC`（用于新生代并行回收）。
+    * `-XX:+UseG1GC`：使用 G1 GC（Garbage-First 回收器）。
+    * `-XX:MaxGCPauseMillis=<time>`：G1 GC 的目标最大停顿时间（毫秒）。G1 会尝试不超过这个时间。
+    * `-XX:ParallelGCThreads=<n>`：设置并行 GC 线程数（用于年轻代回收）。
+    * `-XX:ConcGCThreads=<n>`：设置并发 GC 线程数（用于老年代回收，如 CMS、G1）。
+* **栈内存相关**：
+    * `-Xss<size>`：设置每个线程的栈大小。默认值通常足够，但在递归深度大或线程数多的场景下可能需要调整。
+* **诊断与监控**：
+    * `-XX:+PrintGCDetails`：打印详细的 GC 日志信息。
+    * `-XX:+PrintGCDateStamps`：在 GC 日志中打印日期时间戳。
+    * `-Xloggc:<file>`：将 GC 日志输出到指定文件。
+    * `-XX:+HeapDumpOnOutOfMemoryError`：在发生 OOM 时自动生成堆转储文件（heap dump）。
+    * `-XX:HeapDumpPath=<path>`：指定堆转储文件的生成路径。
+    * `-XX:+PrintCommandLineFlags`：打印 JVM 启动时使用的命令行标志。
+    * `-XX:+UseCompressedOops`：启用压缩普通对象指针（默认启用），节省 64 位 JVM 下的内存占用。
+* **其他**：
+    * `-verbose:gc`：输出简要的 GC 信息到控制台。
+    * `-server` 或 `-client`：指定 JVM 运行模式（现代 JVM 默认使用 Server 模式）。
+      这些只是部分常用参数，JVM 提供了非常丰富的参数用于调优和诊断。
+41. VM 为什么使用元空间替换了永久代？
+    答：JVM（主要是 Oracle 的 HotSpot JVM）从 JDK 8 开始用元空间（Metaspace）替换永久代（PermGen）主要是基于以下几个原因：
+1.  **永久代大小固定且容易溢出**：永久代的大小通过 `-XX:MaxPermSize` 参数设置，默认通常比较小（如 64MB 或 82MB）。随着 Java 应用越来越复杂，加载的类、常量、方法区信息等元数据量急剧增加，很容易就耗尽永久代空间，导致 `java.lang.OutOfMemoryError: PermGen space` 错误。这个问题在框架（如 Spring、Hibernate）广泛使用、OSGi 等动态模块化场景下尤为突出。
+2.  **元数据大小与垃圾回收策略不匹配**：永久代是堆的一部分，使用与老年代相同的分代垃圾回收策略。但是，类加载器本身的生命周期可能与加载的类不同，这导致永久代中存在大量难以回收的垃圾（如卸载的类加载器及其加载的类）。元空间则直接使用本地内存（Native Memory），与堆内存分离，其垃圾回收策略与类加载器的生命周期更匹配，可以更有效地回收不再使用的类元数据。
+3.  **元空间大小更灵活**：元空间默认不设置最大上限（受限于本地内存总量），只有在 `-XX:MaxMetaspaceSize` 被显式设置时才有一个上限。这避免了永久代那种固定上限带来的“突然”溢出问题，使得元空间可以随着应用需要动态扩展，直到达到上限或本地内存耗尽。
+4.  **减少 Full GC 频率**：由于元空间不参与常规的堆内存 GC（除非 `-XX:MaxMetaspaceSize` 被设置且空间不足），将元数据的管理从堆中分离出来，可以减少因永久代回收而触发的 Full GC，从而降低 GC 停顿对应用性能的影响。
+    总的来说，元空间的设计旨在解决永久代空间不足、回收效率低、容易溢出等问题，提供更灵活、更健壮的方法区内存管理方案。
+42. Java堆的结构是什么样子的？什么是堆中的永久代(Perm Gen space)?
+    答：
+* **Java 堆的结构**：Java 堆是 JVM 管理的内存区域中最大的一块，被所有线程共享，主要用于存放对象实例和数组。在分代垃圾回收策略下，堆通常被划分为两个主要区域：
+    * **新生代 (Young Generation)**：新创建的对象首先分配在这里。新生代又细分为：
+        * **Eden 区**：大多数新对象首先分配在这里。
+        * **两个 Survivor 区 (From 和 To)**：用于存放经过一次或多次 Minor GC 后仍然存活的对象。每次 Minor GC 后，Eden 和 From 区中存活的对象会被复制到 To 区，然后 Eden 和 From 区被清空。下一次 Minor GC 时，From 和 To 角色互换。通常只有一个 Survivor 区是活动的。
+    * **老年代 (Old Generation / Tenured Generation)**：在新生代中经历了多次 Minor GC 仍然存活的对象，或者通过 `System.gc()` 强制调用、或者大对象直接分配（取决于配置），会被转移到老年代。老年代主要存放生命周期较长的对象。
+    * **(JDK 8 之前) 永久代 (PermGen Space)**：虽然严格来说永久代不属于堆的一部分（它是方法区在 HotSpot JVM 上的实现），但在 JDK 8 之前，它常常被描述为堆的一部分或与堆紧密相关。它用于存储类的元数据信息（如类定义、常量池、方法信息等）、静态变量、即时编译器编译后的代码等。永久代的大小独立于堆，由 `-XX:MaxPermSize` 控制。
+    * **(JDK 8 及之后) 元空间 (Metaspace)**：取代了永久代，用于存储类的元数据信息。元空间使用本地内存，大小默认只受系统可用内存限制，可通过 `-XX:MaxMetaspaceSize` 设置上限。
+* **什么是堆中的永久代(Perm Gen space)**：这是一个常见的误解。**永久代（PermGen）并不是堆的一部分**。它是 HotSpot JVM 对 Java 规范中“方法区”（Method Area）的一种实现。方法区是 JVM 规范规定的一个逻辑概念区域，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等。在 HotSpot JVM 的早期和 JDK 8 之前，这个区域被具体实现为“永久代”，并且其空间是有限的（由 `-XX:MaxPermSize` 限制），且与 Java 堆分开管理，但两者都由 JVM 管理。由于永久代空间固定且容易溢出，JDK 8 开始用元空间（Metaspace）替代了它，元空间直接使用本地内存，大小更灵活。
+43. JVM的永久代中会发生垃圾回收么？
+    答：是的，JVM 的永久代（PermGen）中会发生垃圾回收，但它的回收机制与堆内存（新生代、老年代）不同。
+* **何时发生**：当永久代空间不足，无法为新的类加载、常量等分配内存时，JVM 会触发 Full GC（全局垃圾回收），其中的一部分工作就是尝试回收永久代中不再使用的内存。
+* **回收什么**：永久代中的垃圾主要是**卸载的类加载器及其加载的类**。当类加载器被垃圾回收器判定为不再被引用（可以被回收）时，其加载的所有类也可以被卸载，从而释放永久代中占用的空间（包括类元数据、静态变量等）。但是，这个过程比较复杂，因为 JVM 需要确保卸载类不会破坏其他仍然活跃的代码。
+* **回收效率**：由于永久代的回收涉及到类卸载，这是一个相对较重的操作，并且其回收效率通常不如新生代和老年代的回收。这也是为什么永久代容易因为加载过多类而导致 OOM，因为即使有很多类加载器被回收，但它们加载的类可能因为引用关系复杂而难以被卸载。
+  总结来说，永久代会发生垃圾回收（通常是 Full GC 的一部分），主要目标是卸载不再需要的类及其相关的元数据，但回收效率和时机不如堆内存灵活。
+44. 什么是字节码？采用字节码的最大好处是什么？什么是Java虚拟机？
+    答：
+* **什么是字节码**：字节码（Bytecode）是 Java 源代码经过编译器（`javac`）编译后生成的一种与具体硬件和操作系统无关的中间代码。它是一系列指令的集合，这些指令的设计是为了能在 Java 虚拟机（JVM）上解释执行或编译执行。字节码文件通常以 `.class` 为扩展名。它不是机器码，不能直接在操作系统上运行。
+* **采用字节码的最大好处**：
+    1.  **平台无关性（Write Once, Run Anywhere - WORA）**：这是最大的好处。由于字节码不依赖特定的硬件架构和操作系统，只要目标机器上安装了对应版本的 JVM，就可以解释或执行这段字节码。这极大地简化了 Java 程序的部署和维护。
+    2.  **提高执行效率**：虽然解释执行字节码比直接执行本地机器码慢，但现代 JVM 通常包含即时编译器（JIT - Just-In-Time Compiler），它可以在运行时将热点代码（频繁执行的代码）编译成本地机器码，从而获得接近原生代码的执行速度。
+    3.  **安全性**：字节码本身可以进行验证，JVM 在加载和执行字节码前会进行一系列安全检查，防止恶意代码破坏系统。
+    4.  **优化可能性**：JVM 可以在运行时对字节码进行各种优化，如内联、逃逸分析、循环展开等，这些优化对于编译器来说可能难以在编译期完成。
+* **什么是Java虚拟机**：Java 虚拟机（Java Virtual Machine，简称 JVM）是一个虚拟的计算机，它是一种抽象的机器模型。它并不真实存在，而是运行在物理计算机上的一个进程。JVM 的主要任务是：
+    1.  **加载**：从文件系统或网络加载 `.class` 字节码文件。
+    2.  **验证**：确保加载的字节码符合 JVM 规范，不会破坏其安全。
+    3.  **准备**：为类变量分配内存并设置默认初始值。
+    4.  **解析**：将符号引用（如方法名、字段名）解析为直接引用（内存地址）。
+    5.  **解释/编译执行**：将字节码翻译成特定操作系统和硬件平台能够理解的本地机器指令并执行。这通常通过解释器完成，热点代码会由 JIT 编译器编译成本地代码以提高性能。
+    6.  **内存管理**：管理 JVM 内部的内存区域（堆、栈、方法区/元空间等），包括内存分配和垃圾回收。
+    7.  **提供运行时环境**：为 Java 程序提供执行所需的环境，包括类库、安全管理器等。
+        简单来说，JVM 是 Java 程序运行的基础，它实现了 Java 的跨平台特性，并负责管理内存、执行代码等核心功能。
+45. MinorGC 的过程
+    答：Minor GC（也称为 Young GC）是针对 Java 堆中新生代区域的垃圾回收过程。其目标是回收 Eden 区和 From Survivor 区中不再被引用的对象，并将存活的对象移动到 To Survivor 区或老年代。主要过程如下：
+1.  **标记 (Mark)**：GC 线程会从 Eden 区和 From Survivor 区存活的对象开始，遍历它们的引用链，标记所有可达（仍然被引用）的对象。所有未被标记的对象被认为是垃圾。
+2.  **复制 (Copy)**：GC 线程将 Eden 区和 From Survivor 区中所有被标记为存活的对象复制到 To Survivor 区。在复制过程中，对象的年龄（Age，表示对象经历过多少次 Minor GC 仍然存活）会增加 1。
+3.  **清理/清空 (Sweep/Clear)**：Eden 区和 From Survivor 区被清空，因为它们中的所有存活对象都已经被复制到 To Survivor 区，未被复制的对象（垃圾）可以被回收。
+4.  **更新指针**：更新指向这些存活对象的引用，使其指向 To Survivor 区的新位置（如果对象被移动了）。
+5.  **角色互换**：Eden 区保持不变，From Survivor 区和 To Survivor 区的角色互换。下一次 Minor GC 时，当前 To Survivor 区会变成 From Survivor 区，反之亦然。
+6.  **年龄晋升 (Promotion)**：在复制过程中，如果对象的年龄达到一定阈值（由 `-XX:MaxTenuringThreshold` 参数控制，默认 15），或者对象的大小超过了 survivor 区的容量，或者进行了一次 Minor GC 后，对象仍然存活但 survivor 区放不下，这些对象会被直接复制到老年代。
+    Minor GC 通常比较快速，因为它只处理新生代区域，对象存活率相对较低。但每次 Minor GC 都会引起一次短暂的 Stop The World（STW），暂停应用程序线程。
+46. CPU 占用过高如何分析
+    答：分析 Java 应用 CPU 占用过高的问题通常需要结合多种工具和方法，步骤大致如下：
+1.  **确认问题**：使用操作系统工具（如 `top`, `htop`, `vmstat`, `ps aux | grep java`）确认是哪个 Java 进程 CPU 占用率高，以及是哪个 CPU 核心或所有核心都高。
+2.  **获取线程快照**：使用 `jstack <pid>` 命令获取 JVM 的线程堆栈信息。多次获取（如间隔几秒获取几次）可以观察线程状态的变化。
+3.  **分析线程堆栈**：
+    *   在 `jstack` 输出中，查找 `java.lang.Thread.State: RUNNABLE` 的线程，特别是那些占用 CPU 最高的线程（可以通过 `top -H -p <pid>` 查看每个线程的 CPU 占用，然后找到对应的线程 ID，再在 `jstack` 输出中查找该线程 ID 对应的堆栈）。
+    *   分析这些线程正在执行什么代码。堆栈信息会显示线程当前正在执行的类、方法和行号。
+    *   常见的高 CPU 消耗原因包括：死循环、频繁的字符串拼接（使用 `+` 号而非 `StringBuilder`）、低效的算法、过多的锁竞争、频繁的 GC（尤其是 Full GC）、大量 I/O 操作（如网络请求、文件读写）等。
+4.  **使用 Profiler 工具**：使用专业的 Java Profiler 工具（如 VisualVM, JProfiler, YourKit, Async Profiler 等）进行更深入的分析。
+    *   **CPU Profiling**：Profiler 可以统计方法调用的耗时，找出消耗 CPU 时间最多的热点方法（Hotspot Methods）。这能直接定位到代码层面的性能瓶颈。
+    *   **火焰图 (Flame Graph)**：许多现代 Profiler 支持 Flame Graph，直观地展示调用栈和各层级的 CPU 消耗比例，非常适合快速定位热点。
+    *   **锁分析**：检查是否存在线程因等待锁而阻塞，导致线程切换开销增大，间接导致 CPU 占用高。
+5.  **结合业务逻辑**：分析找到的热点代码或死循环，结合业务逻辑判断是否是预期行为（比如高峰期处理大量请求），还是代码缺陷或设计问题。
+6.  **优化**：根据分析结果进行代码优化，如改进算法、减少锁竞争、优化 I/O 操作、避免不必要的计算等。
+    整个过程需要耐心和细致，可能需要多次抓取和分析数据才能找到根本原因。
+47. Serial与Parallel GC之间的不同之处？
+    答：Serial GC 和 Parallel GC 是 HotSpot JVM 中两种不同的垃圾回收器，主要区别在于：
+1.  **工作线程数量**：
+    *   **Serial GC**：使用单个 GC 线程进行垃圾回收。无论是新生代回收（Minor GC）还是老年代回收（Full GC），都只依赖一个线程。
+    *   **Parallel GC**（也称为 Throughput Collector）：使用多个 GC 线程并行进行垃圾回收，特别是在新生代回收（Minor GC）阶段。老年代回收（Full GC）阶段，Parallel GC 通常会退化为 Serial Old（串行老年代回收器），即使用单个线程。
+2.  **适用场景**：
+    *   **Serial GC**：适用于单核 CPU 或 CPU 核心数较少、内存较小的场景。因为它不涉及多线程同步开销，在资源受限的环境下可能表现更好。是 Client 模式 JVM 的默认回收器。
+    *   **Parallel GC**：适用于多核 CPU、追求高吞吐量的场景。通过并行回收可以显著缩短 Minor GC 的停顿时间，提高应用程序的整体吞吐量（用户代码执行时间 / (用户代码执行时间 + GC 时间)）。是 Server 模式 JVM 的默认回收器（在较新版本中可能默认是 G1）。
+3.  **停顿时间 (Pause Time)**：
+    *   **Serial GC**：由于只使用一个线程， Minor GC 和 Full GC 的停顿时间通常较长，因为所有用户线程都需要暂停（STW）来等待 GC 完成。
+    *   **Parallel GC**：Minor GC 由于使用了多个线程并行处理，停顿时间通常比 Serial GC 短（在多核机器上）。但 Full GC（如果使用 Serial Old）仍然会有较长的停顿。
+4.  **吞吐量 (Throughput)**：
+    *   **Serial GC**：吞吐量相对较低，因为 GC 线程占用了 CPU 资源，且单线程回收速度较慢。
+    *   **Parallel GC**：设计目标是提高吞吐量，通过并行回收减少 GC 时间，让更多 CPU 时间用于应用程序执行。
+5.  **内存占用**：
+    *   **Serial GC**：内存占用较低，因为它不需要为多个 GC 线程分配额外的内存空间。
+    *   **Parallel GC**：可能需要更多的内存用于多线程并行处理，例如需要额外的数据结构来支持并行标记、复制等操作。
+        总结：Parallel GC 是 Serial GC 的多线程版本，主要优势在于多核环境下的性能提升，特别是缩短 Minor GC 停顿时间和提高吞吐量。选择哪个取决于应用对停顿时间和吞吐量的具体要求以及硬件环境。
+48. WeakHashMap 是怎么工作的？
+    答：`WeakHashMap` 是 Java 集合框架中的一种特殊的 `Map` 实现，它与普通的 `HashMap` 不同之处在于，它对键（Key）使用弱引用（`WeakReference`）。其工作原理如下：
+1.  **键的弱引用**：`WeakHashMap` 中的每个键都是一个 `WeakReference` 对象。这意味着当除了 `WeakHashMap` 之外没有其他强引用指向该键对象时，这个键对象就成为垃圾回收的候选对象。即使 `WeakHashMap` 中还持有该键的引用，GC 仍然可以回收它。
+2.  **值的强引用**：`WeakHashMap` 对值（Value）仍然使用强引用（普通的对象引用）。只要 `WeakHashMap` 中持有对值的引用，或者外部有其他强引用指向该值，该值就不会被 GC 回收。
+3.  **引用队列 (Reference Queue)**：`WeakHashMap` 内部维护了一个 `ReferenceQueue`。当 GC 回收了一个 `WeakReference` 键对象时，这个 `WeakReference` 对象本身（注意，不是它引用的键对象）会被加入到这个队列中。
+4.  **清理机制**：`WeakHashMap` 会定期（或在某些操作如 `get`, `put` 时）检查这个 `ReferenceQueue`。如果发现有 `WeakReference` 对象进入队列，说明对应的键已经被 GC 回收了，`WeakHashMap` 会从自身映射中移除这些键值对，从而释放对值对象的引用，让值对象也能被 GC 回收。
+    **主要用途**：`WeakHashMap` 适用于需要缓存数据，但又不希望缓存对象阻止其被 GC 回收的场景。例如，缓存一些临时计算结果，当系统内存紧张时，这些缓存可以被自动清除，避免内存溢出。它常用于缓存与类加载器相关的资源，当类加载器被 GC 时，其加载的类相关的缓存数据也能随之被清除。
+49. 解释 Java 堆空间及 GC？
+    答：
+* **Java 堆空间**：Java 堆是 JVM 所管理内存中最大的一块，是所有线程共享的内存区域。它的主要作用是存储几乎所有的对象实例和数组。堆在 JVM 启动时创建，用于动态内存分配。为了提高垃圾回收效率，堆通常被划分为不同的区域，最常见的是分代模型，将堆划分为新生代（Young Generation）和老年代（Old Generation）。新生代又细分为 Eden 区和两个 Survivor 区，用于存放新创建的对象。老年代用于存放生命周期较长的对象，通常是经过多次 Minor GC 仍然存活的对象会被移动到这里。
+* **垃圾回收 (GC)**：垃圾回收是 JVM 自动管理内存的一种机制，其目的是自动检测并回收那些不再被任何引用指向的对象所占用的内存，从而避免程序员手动管理内存带来的复杂性和错误（如内存泄漏、内存溢出）。GC 主要通过以下步骤实现：
+    1.  **标记 (Mark)**：GC 线程从一组根对象（如全局变量、栈中的局部变量和参数、JNI 引用等）开始，遍历所有可达的对象，标记它们为“存活”。
+    2.  **清除/复制/整理 (Sweep/Copy/Compact)**：根据不同的 GC 算法，采取不同的策略处理未被标记的对象（即垃圾）：
+        *   **标记-清除 (Mark-Sweep)**：标记所有存活对象，然后清除所有未被标记的对象（将其占用的内存标记为可分配）。会产生内存碎片。
+        *   **标记-复制 (Mark-Copy)**：将存活对象复制到一块新的内存区域（通常是新生代的另一个 Survivor 区或一块专门的内存），然后清空原来的内存区域。适用于存活率低的区域（如新生代），不会产生碎片，但会浪费一部分空间。
+        *   **标记-整理 (Mark-Compact)**：标记存活对象，然后将所有存活对象移动到内存的一端，清除另一端的内存。适用于存活率高的区域（如老年代），不会产生碎片，但移动对象成本较高。
+    3.  **回收**：释放被确定为垃圾的对象所占用的内存空间，使其可以被重新分配给新的对象。
+        不同的 GC 算法（如 Serial GC, Parallel GC, CMS GC, G1 GC, ZGC）在标记和清理/复制/整理阶段使用不同的策略，以平衡内存回收的效率、停顿时间和内存碎片等问题。
+50. 你能保证 GC 执行吗？
+    答：不能。Java 虚拟机的设计原则之一是自动管理内存，程序员无法精确控制或保证垃圾回收（GC）何时发生。GC 的触发时机由 JVM 的垃圾回收器根据其内部算法和当前内存使用情况自动决定。虽然提供了 `System.gc()` 和 `Runtime.gc()` 方法，但调用它们**并不保证**会立即触发 GC，也不能保证 GC 一定会执行。
+    调用 `System.gc()` 或 `Runtime.gc()` 只是向 JVM 发出一个**建议**，请求 JVM 尽快执行 GC。JVM 可以选择忽略这个请求，或者根据当前状态决定是否以及何时执行 GC。这种设计是为了避免程序员通过频繁调用 GC 来“优化”内存使用，因为强制 GC 可能会带来额外的性能开销，并且可能破坏 JVM 自身的优化策略（如 JIT 编译、内存分配策略等）。
+    因此，正确的做法是信任 JVM 的自动内存管理机制，专注于编写内存使用高效的代码，并在必要时通过监控和分析工具来了解 GC 的行为和内存使用情况，而不是试图去“保证”或“强制”GC 的执行。
+51. JVM中哪个参数是用来控制线程的栈堆栈小的?
+    答：在 JVM 中，用来控制每个线程栈大小的参数是 `-Xss`（或 `-XX:ThreadStackSize`）。
+*   **格式**：`-Xss<size>`
+*   **说明**：这个参数指定了每个线程创建时分配的栈空间大小。例如，`-Xss1m` 表示每个线程分配 1MB 的栈空间。
+*   **影响**：
+    *   栈空间主要用于存储局部变量、操作数栈、方法调用信息等。每个方法调用都会在栈上创建一个栈帧，如果栈空间不足，就会抛出 `java.lang.StackOverflowError`（通常由递归过深或栈帧过大引起）或 `java.lang.OutOfMemoryError: unable to create new native thread`（当系统无法为新线程分配足够的栈空间时，通常因为 `-Xss` 设置过大或系统资源耗尽）。
+    *   在内存资源有限的环境下，减小 `-Xss` 可以允许创建更多的线程，但可能会增加栈溢出的风险。反之，增大 `-Xss` 可以减少栈溢出的风险，但会减少可创建的线程数量。
+        通常，JVM 会为不同操作系统和模式（Server/Client）设置一个默认的栈大小。在 64 位系统上，默认栈大小可能较大（如 1MB），而在 32 位系统上可能较小（如 256KB 或 512KB）。根据应用的需求和硬件资源，可能需要调整这个参数。

From d76a913537de341b07599cc0b9da787831986d4a Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Wed, 25 Jun 2025 15:41:42 +0800
Subject: [PATCH 4/9] =?UTF-8?q?=E8=A1=A5=E5=85=85=E7=AD=94=E6=A1=88?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...30\351\235\242\350\257\225\351\242\230.md" | 448 +++++++++++++++++-
 1 file changed, 437 insertions(+), 11 deletions(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230.md"
index 90fc9d3..9d81bf1 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230.md"
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\347\274\223\345\255\230\351\235\242\350\257\225\351\242\230.md"
@@ -1,71 +1,497 @@
 ### 缓存/Redis
-1. Redis用过哪些数据类型，每种数据类型的使用场景
-2. Redis缓存穿透、缓存雪崩和缓存击穿原因，以及解决方案
-3. 如何使用Redis来实现分布式锁，redis分布式锁有什么缺陷？
-4. Redis 持久化机制，有几种方式，优缺点是什么，怎么实现的，RDB和AOF的区别
-5. Redis集群，高可用，原理。
-6. Redis的数据淘汰策略
-7. 为什么要用redis？为什么要用缓存，在哪些场景使用缓存
-8. redis事务，了解吗，了解Redis事务的CAS操作吗
-9. 如何解决 Redis 的并发竞争Key问题。
+1.  Redis用过哪些数据类型，每种数据类型的使用场景
+    答：Redis常用的数据类型包括：
+    *   **字符串（String）**：存储简单的键值对，如用户会话信息、计数器、共享状态等。
+    *   **哈希（Hash）**：存储对象，如用户信息（用户ID为键，用户名、年龄等为字段和值），适合结构化数据存储。
+    *   **列表（List）**：存储有序的字符串集合，如消息队列、微博时间线、排行榜（简单版）。
+    *   **集合（Set）**：存储无序且不重复的字符串，如标签系统、共同好友、抽奖活动（去重）。
+    *   **有序集合（Sorted Set）**：存储不重复字符串，且每个元素关联一个分数，如排行榜、带权重的任务队列。
+2.  Redis缓存穿透、缓存雪崩和缓存击穿原因，以及解决方案
+    答：
+    *   **缓存穿透**：原因：大量请求查询不存在的数据，缓存不命中，请求全部打到数据库。解决方案：接口层增加校验，如ID必须大于0；缓存空对象（设置较短的TTL）；布隆过滤器（Bloom Filter）。
+    *   **缓存雪崩**：原因：大量缓存Key同时失效，或者Redis服务宕机，导致大量请求涌入数据库。解决方案：设置不同的TTL时间；使用Redis集群提高可用性；服务降级；限流。
+    *   **缓存击穿**：原因：某个热点Key突然失效，大量请求同时访问该Key，导致数据库压力骤增。解决方案：互斥锁（保证只有一个请求去查库并更新缓存）；逻辑过期（缓存中存储逻辑过期时间，后台线程异步更新）；永不过期（不设置TTL，但需要额外机制感知数据变更）。
+3.  如何使用Redis来实现分布式锁，redis分布式锁有什么缺陷？
+    答：使用Redis实现分布式锁通常使用`SET key value NX PX milliseconds`命令。获取锁的流程：SET一个唯一值（如UUID）作为value，设置NX（不存在才设置）和PX（设置过期时间）。释放锁：通过Lua脚本判断value是否为当前线程设置的值，是则执行DEL。
+    缺陷：
+    *   **网络抖动**：可能导致锁无法获取或释放。
+    *   **主从切换**：如果Redis是主从架构，主节点刚设置锁就宕机，从节点提升为主，锁会丢失。
+    *   **锁过期时间设置**：设置过短可能导致业务未完成锁就过期；设置过长可能导致持有锁的进程崩溃后锁无法释放。
+    *   **不可重入**：默认实现不支持同一线程多次获取同一把锁。
+    *   **锁无法被延长**：如果持有锁的进程处理时间超过TTL，锁会自动释放，其他进程可能获取到锁，导致数据不一致。
+4.  Redis 持久化机制，有几种方式，优缺点是什么，怎么实现的，RDB和AOF的区别
+    答：Redis主要有两种持久化机制：RDB（Redis Database）和AOF（Append Only File）。
+    *   **RDB**：
+        *   优点：生成单一文件，适合备份和迁移；恢复速度快；对性能影响较小（只在保存点时阻塞）。
+        *   缺点：数据有丢失风险（取决于保存间隔）；保存时可能产生fork耗时。
+        *   实现：通过`SAVE`（阻塞式）或`BGSAVE`（后台fork子进程）命令，将内存中的数据集快照保存到磁盘的`.rdb`文件中。可以配置保存策略（如`save 900 1`表示900秒内有1个键变化则触发）。
+    *   **AOF**：
+        *   优点：数据更安全，丢失数据量可控（秒级或更少）；支持Append模式，追加写性能较好。
+        *   缺点：文件体积通常比RDB大；恢复速度比RDB慢；对性能有一定影响（需要写入磁盘）。
+        *   实现：记录所有写命令到AOF文件末尾。可以通过`appendfsync`配置同步频率（always/everysec/no）。支持AOF重写（`BGREWRITEAOF`），压缩AOF文件大小。
+    *   **区别**：RDB是快照，AOF是命令日志；RDB恢复快但可能丢失数据，AOF安全但恢复慢且文件大；通常建议两者结合使用。
+5.  Redis集群，高可用，原理。
+    答：Redis集群通过数据分片（Sharding）和主从复制（Replication）实现高可用和横向扩展。
+    *   **原理**：将整个数据集划分为多个槽（Slot，共16384个），每个节点负责一部分槽。客户端通过哈希算法（如CRC16）计算Key对应的槽，然后路由到负责该槽的节点。每个槽由一个主节点（Master）负责，并可以有一个或多个从节点（Slave）进行数据复制。当主节点故障时，哨兵（Sentinel）或集群自身会自动将从节点提升为主节点，保证服务不中断。
+    *   **高可用**：依赖于主从复制和故障转移机制。哨兵模式（Redis Sentinel）是早期常用方案，负责监控、通知和自动故障转移。Redis Cluster 3.0+ 内置了部分高可用功能（节点故障检测和主从切换）。
+6.  Redis的数据淘汰策略
+    答：Redis提供了多种数据淘汰策略，当内存不足时决定如何淘汰数据：
+    *   **noeviction**：默认策略，不淘汰任何数据，写入失败（返回OOM错误）。
+    *   **volatile-ttl**：在设置了过期时间的键中，淘汰TTL最短的键。
+    *   **volatile-random**：在设置了过期时间的键中，随机淘汰。
+    *   **volatile-lru**：在设置了过期时间的键中，使用LRU（最近最少使用）算法淘汰。
+    *   **volatile-lfu**：在设置了过期时间的键中，使用LFU（最不经常使用）算法淘汰。
+    *   **allkeys-lru**：在所有键中，使用LRU算法淘汰。
+    *   **allkeys-random**：在所有键中，随机淘汰。
+    *   **allkeys-lfu**：在所有键中，使用LFU算法淘汰。
+7.  为什么要用redis？为什么要用缓存，在哪些场景使用缓存
+    答：
+    *   **为什么要用Redis**：因为Redis是高性能的内存数据库，支持多种数据结构，具备持久化能力，支持发布/订阅、事务等，且部署简单，社区活跃。它特别适合需要快速读写、结构化数据存储、分布式锁等场景。
+    *   **为什么要用缓存**：缓存用于存储热点数据，减少对后端数据库（如MySQL）的访问压力，提高系统响应速度和吞吐量，改善用户体验。
+    *   **使用场景**：会话缓存（Session Cache）、商品信息缓存、用户信息缓存、排行榜、计数器、分布式锁、消息队列、缓存数据库查询结果等。
+8.  redis事务，了解吗，了解Redis事务的CAS操作吗
+    答：了解。Redis事务通过`MULTI`、`EXEC`、`DISCARD`、`WATCH`命令实现。
+    *   `MULTI`开始一个事务块，后续命令会排队。
+    *   `EXEC`执行事务块中所有排队命令。
+    *   `DISCARD`取消事务块，放弃所有排队命令。
+    *   `WATCH`用于监视一个或多个键，如果在`EXEC`执行前这些键被其他客户端修改，则事务会失败（返回空结果）。这类似于CAS（Compare-And-Swap）操作，确保在执行事务期间，被监视的键没有被修改，提供一定的原子性和一致性保证。
+9.  如何解决 Redis 的并发竞争Key问题。
+    答：可以通过以下方式解决：
+    *   **分布式锁**：使用Redis的SET NX PX命令获取锁，确保同一时间只有一个线程能操作该Key，操作完成后释放锁。
+    *   **消息队列/任务队列**：将需要竞争Key的操作放入队列，由消费者顺序处理，避免并发。
+    *   **使用Redis事务（WATCH）**：监视Key，如果Key在事务执行前被修改，则重试或放弃。
+    *   **版本号控制**：在Key的值中包含版本号，更新时检查版本号是否匹配。
 10. Redis为什么是单线程的，为什么单线程还这么快？
+    答：
+    *   **为什么是单线程**：Redis的网络I/O和键值操作（核心逻辑）主要由一个线程处理，主要是为了简化开发、减少多线程竞争（锁）带来的性能损耗，以及保证命令的原子性。虽然后续版本引入了多线程用于部分耗时操作（如RDB/AOF重写），但核心事件循环和命令处理仍是单线程。
+    *   **为什么快**：
+        *   **纯内存操作**：数据存储在内存中，读写速度极快。
+        *   **高效的数据结构**：针对不同场景优化了数据结构（如哈希表、跳跃表、整数集合等）。
+        *   **I/O多路复用**：使用epoll（Linux）、kqueue（BSD/macOS）等机制，单线程可以高效处理大量并发连接的网络I/O。
+        *   **非阻塞I/O**：网络I/O是异步的，不会阻塞主线程处理其他命令。
 11. 如何保证缓存与数据库双写时的数据一致性?
+    答：这是一个复杂的问题，没有绝对完美的方案，通常采用以下策略组合：
+    *   **先更新数据库，再更新缓存**：这是常见做法。但如果缓存更新失败，会导致不一致。可以通过重试机制解决。
+    *   **先删除缓存，再更新数据库**：适用于读多写少场景。更新数据库后立即删除缓存，下次读请求会去数据库加载新数据并回填缓存。但存在窗口期不一致问题（旧数据可能在缓存中）。
+    *   **延时双删**：先删除缓存，再更新数据库，然后延时一段时间（如1秒）再删除一次缓存，确保在窗口期内加载到旧数据的请求被拦截。
+    *   **数据库触发器**：在数据库更新时触发一个操作去更新/删除缓存，但耦合度高，不易维护。
+    *   **消息队列（MQ）**：数据库更新后发送消息到MQ，消费者监听MQ并更新/删除缓存。可以实现最终一致性，但引入了新的复杂度。
+    *   **业务逻辑控制**：在业务层面保证，如在一个事务中完成数据库更新和缓存更新/删除。
 12. redis和memcached有什么区别
+    答：
+    *   **数据类型**：Redis支持多种数据结构（String, Hash, List, Set, Sorted Set等），Memcached只支持简单的Key-Value字符串。
+    *   **持久化**：Redis支持RDB和AOF持久化，Memcached默认不持久化（除非使用第三方插件）。
+    *   **内存管理**：Redis使用更复杂的内存管理方式（如ziplist、intset等压缩结构），Memcached使用预分配的内存池。
+    *   **分布式**：Redis有内置的集群支持（Redis Cluster），Memcached需要客户端或代理（如Twemproxy）实现分布式。
+    *   **单线程 vs 多线程**：Redis核心是单线程（但网络I/O是多线程的），Memcached是多线程的。
+    *   **功能丰富度**：Redis功能更丰富，支持事务、发布/订阅、Lua脚本等，Memcached相对简单。
 13. JVM本地缓存，了解过吗
+    答：了解。JVM本地缓存是指直接在Java应用程序的JVM内存中存储数据的缓存，不依赖外部服务。常见的实现有：
+    *   **Caffeine**：高性能的Java缓存库，基于窗口LRU/W-TinyLFU算法，是目前推荐使用的。
+    *   **Guava Cache**：Google Guava库提供的缓存实现，功能稳定，使用广泛。
+    *   **Ehcache**：功能强大的缓存框架，支持本地缓存和分布式缓存。
+    *   **ConcurrentHashMap**：最简单的实现，但需要手动处理过期、淘汰等逻辑。
+    它们通常提供自动加载、过期策略、大小限制、并发控制等功能。
 14. redis的list结构相关的操作。
+    答：Redis的List（列表）是基于双向链表（或压缩列表）实现的，主要操作包括：
+    *   **LPUSH / RPUSH**：在列表头部/尾部添加一个或多个元素。
+    *   **LPOP / RPOP**：移除并返回列表头部/尾部的第一个元素（模拟栈/队列）。
+    *   **LRANGE**：获取列表指定范围内的元素。
+    *   **LLEN**：获取列表长度。
+    *   **LINDEX**：获取列表指定索引位置的元素。
+    *   **LREM**：移除列表中指定数量的等于某个值的元素。
+    *   **LSET**：设置列表指定索引位置的元素值。
+    *   **LTRIM**：修剪列表，只保留指定范围内的元素。
+    *   **BLPOP / BRPOP**：阻塞式弹出，当列表为空时阻塞，直到有元素可弹出或超时（常用于实现阻塞队列）。
+    *   **RPOPLPUSH / BRPOPLPUSH**：原子性地从源列表弹出尾部元素并推入目标列表头部（常用于实现工作窃取）。
 15. redis2和redis3的区别，redis3内部通讯机制。
+    答：
+    *   **Redis 2 vs Redis 3**：
+        *   Redis 3.0引入了Redis Cluster，实现了内置的自动分片和故障转移，这是最核心的区别。
+        *   Redis 3.0对性能和稳定性进行了优化。
+        *   引入了`CONFIG REWRITE`命令，优化配置文件的生成。
+        *   增加了一些新命令和功能。
+    *   **Redis 3内部通讯机制（集群）**：
+        集群节点之间通过TCP通信，使用一种称为“Gossip”的协议来交换信息，主要包括：
+        *   **节点发现**：新节点通过 handshake 机制加入集群，并从其他节点获取集群成员信息。
+        *   **状态同步**：节点定期向其他节点发送ping消息，包含自己的状态和一些随机节点信息，接收方回复pong。通过这种方式传播节点的状态（在线、下线、疑似下线等）。
+        *   **故障检测**：如果节点没有收到某个节点的pong响应，会标记为疑似下线（PFAIL），然后通过Gossip消息传播，当多数主节点都认为某个主节点疑似下线时，会标记为下线（FAIL），并开始故障转移流程。
+        *   **消息类型**：包括meet（握手）、ping、pong、fail（故障通知）、ping-ack等。
 16. Redis的选举算法和流程是怎样的？
+    答：Redis的选举（主节点选举）发生在主节点故障，其从节点需要提升为主节点时。选举流程主要由哨兵（Sentinel）或Redis Cluster自身控制：
+    *   **发现故障**：哨兵或集群节点检测到主节点故障。
+    *   **发起选举**：故障主节点的从节点会参与选举。
+    *   **选举条件**：通常选择优先级最高、数据最新（复制偏移量最大）、runid最小的从节点。
+    *   **投票**：在哨兵模式下，由达到法定票数的哨兵投票决定新的主节点。在Redis Cluster中，由集群内多数主节点投票决定。
+    *   **提升主节点**：获得足够票数的从节点被提升为主节点，并通知其他从节点更新配置。
+    *   **通知客户端**：新的主节点和哨兵/集群会通知客户端更新连接地址。
 17. Reids的主从复制机制原理。
+    答：Redis主从复制（Replication）原理：
+    1.  **建立连接**：从节点向主节点发送`SYNC`命令（在旧版）或`PSYNC`命令（在新版，支持部分重同步）。
+    2.  **全量同步**：主节点收到`SYNC`或`PSYNC`（无偏移量）后，执行以下步骤：
+        *   执行`BGSAVE`生成RDB快照文件。
+        *   将所有缓存的写命令（AOF缓冲区）发送给从节点。
+        *   RDB文件生成后，通过网络发送给从节点。
+        *   从节点接收RDB文件并加载到内存，然后接收并执行缓存的写命令。
+    3.  **部分同步**（`PSYNC`支持）：如果从节点能提供有效的复制偏移量和run id，主节点会检查自己的缓冲区，如果存在对应偏移量的命令，则只发送这部分增量数据给从节点，避免全量同步。
+    4.  **命令传播**：全量/部分同步完成后，主节点会将后续发生的所有写命令实时异步地发送给从节点，保证数据一致性。
+    5.  **从节点角色**：从节点默认不对外服务，只读。可以通过配置让其可写，但数据最终以主节点为准。
 18. Redis的线程模型是什么？
+    答：Redis的核心线程模型是**单线程事件循环模型**。主线程负责：
+    *   **事件循环**：使用I/O多路复用机制（如epoll）监听多个socket的事件（连接、可读、可写）。
+    *   **命令处理**：当socket可读时，主线程读取客户端请求，解析命令，并在内存中执行命令（如更新键值）。
+    *   **网络写入**：当socket可写时，主线程将命令执行结果写入socket发送给客户端。
+    虽然核心是单线程，但Redis 4.0+ 引入了多线程来处理一些耗时的后台任务，如`BGREWRITEAOF`和`BGSAVE`，以减轻主线程负担，提高性能。
 19. Redis的使用要注意什么，讲讲持久化方式，内存设置，集群的应用和优劣势，淘汰策略等。
+    答：
+    *   **注意事项**：
+        *   合理设置Key的过期时间，避免内存无限增长。
+        *   避免使用`KEYS *`等命令阻塞服务，使用`SCAN`代替。
+        *   大Key、热Key问题要关注，避免影响性能。
+        *   正确配置持久化，平衡数据安全性和性能。
+        *   监控Redis实例状态（内存、CPU、连接数、延迟等）。
+    *   **持久化方式**：见问题4。RDB适合备份，AOF适合数据安全。通常两者结合。
+    *   **内存设置**：通过`maxmemory`设置最大使用内存，通过`maxmemory-policy`设置淘汰策略。根据应用场景选择合适的单位（MB、GB等）。
+    *   **集群应用**：
+        *   **应用**：解决单机内存瓶颈，实现高可用和横向扩展。
+        *   **优势**：支持更大规模数据，高可用性（自动故障转移），读写性能可扩展（分片）。
+        *   **劣势**：客户端实现复杂（需要处理槽分配、重定向等），不支持跨节点事务，某些命令（如`KEYS`）在集群中受限或需要特殊处理，运维相对复杂。
+    *   **淘汰策略**：见问题6。根据数据访问模式和重要性选择，如读多写少用`allkeys-lru`，有明确冷热数据区分用`volatile-lru`。
 20. Redis缓存分片
+    答：Redis缓存分片（Sharding）是指将缓存数据分散存储到多个Redis实例中，目的是突破单机内存限制，提高缓存容量和并发处理能力。常见的分片策略有：
+    *   **客户端分片**：在客户端代码中实现分片逻辑，如使用一致性哈希（Consistent Hashing）将Key映射到特定实例。优点是简单直接，缺点是客户端代码复杂，扩展性差。
+    *   **代理分片**：使用一个中间代理层（如Twemproxy、Codis）接收所有请求，代理根据分片规则将请求转发到正确的Redis实例。优点是客户端透明，缺点是引入了单点故障和性能瓶颈。
+    *   **服务端分片**：Redis Cluster就是典型的服务端分片，将数据划分为16384个槽，每个节点负责一部分槽。客户端（如Lettuce、Jedis的集群模式）需要知道槽的分布，或者由服务端（MOVED/ASK重定向）告知。这是目前主流的方案。
 21. redis的集群怎么同步的数据的？
+    答：Redis集群的数据同步是通过**主从复制（Replication）**机制实现的。集群中的每个数据分片（Slot）由一个主节点（Master）负责，并可以配置一个或多个从节点（Slave）。主节点将数据的变更（写命令）通过命令传播的方式实时异步地发送给其所有的从节点，从节点接收并执行这些命令，从而保持与主节点的数据一致。当主节点故障时，其从节点会被提升为主节点，并通过复制机制从其他主节点（或其从节点）同步数据，最终达到数据一致。
 22. 请思考一个方案，设计一个可以控制缓存总体大小的自动适应的本地缓存。
+    答：可以设计一个基于`Caffeine`或`Guava Cache`的本地缓存，并添加自适应控制逻辑：
+    *   **基础缓存**：使用Caffeine，设置一个初始的最大大小（如`maximumSize`）。
+    *   **监控机制**：定期（如每分钟）检查当前缓存的实际大小（元素数量或估算内存占用）。
+    *   **自适应调整**：
+        *   **扩容**：如果缓存大小接近上限，但命中率仍然很高，可以适当增加`maximumSize`（如增加10%）。
+        *   **缩容**：如果缓存大小接近上限，且命中率下降，可以减少`maximumSize`（如减少10%）。或者，如果系统整体内存紧张，可以强制减少`maximumSize`。
+    *   **淘汰策略**：始终启用高效的淘汰策略（如`evictionPolicy`设置为LRU或LFU）。
+    *   **加载策略**：对于频繁访问但未缓存的数据，实现自动加载逻辑。
+    *   **实现**：可以通过扩展Caffeine的`Cache`或`LoadingCache`，或者封装一层，在put/get操作和定期任务中实现上述逻辑。
 23. redis的哨兵模式，一个key值如何在redis集群中找到存储在哪里。
+    答：
+    *   **哨兵模式**：哨兵（Sentinel）本身不直接提供数据分片功能。它主要负责监控Redis主从节点的健康状态，在主节点故障时自动进行故障转移（Failover），选举新的主节点，并通知客户端更新连接信息。客户端需要自己实现或者依赖客户端库来实现连接逻辑。
+    *   **在哨兵模式下找Key位置**：客户端通常连接到哨兵实例，哨兵会返回当前可用的主节点地址。客户端连接到主节点后，如果应用了Redis Cluster的分片逻辑（如一致性哈希），客户端会根据Key计算应该去哪个节点（在哨兵模式下，通常就是主节点，除非Key在从节点上）。如果没有分片逻辑，客户端默认连接的主节点就是访问的节点（简单主从，所有写和部分读都在主节点）。
 24. Redis，一个字符串类型的值能存储最大容量是多少？
+    答：Redis字符串类型的值最大可以存储 **512MB** 的数据。
 25. MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据？
+    答：可以通过以下几种策略结合保证Redis中存储的是热点数据：
+    *   **基于访问频率**：记录每个Key的访问次数，定期（如每小时）将访问次数最高的N个Key（这里是20w个）加载到Redis中。
+    *   **基于LRU/LFU算法**：在Redis中设置`allkeys-lru`或`allkeys-lfu`淘汰策略，并设置`maxmemory`为适当大小。这样，当有新数据需要缓存时，会自动淘汰掉最近最少使用或最不频繁使用的旧数据，确保缓存中始终是最近最常访问的热点数据。
+    *   **机器学习预测**：利用历史访问数据训练模型，预测未来的热点数据，提前加载到Redis。
+    *   **组合策略**：例如，结合LRU和访问频率，优先缓存访问频率高且近期被访问过的数据。
 26. Redis和Redisson有什么关系？
+    答：Redis 是一个开源的、内存中的数据结构存储系统，可以用作数据库、缓存和消息中间件。它本身提供了一套命令行接口（CLI）和简单的客户端库（如 Jedis、Lettuce 等）供开发者使用。
+    Redisson 是 Redis 的一个 Java 客户端实现，但它不仅仅是一个简单的客户端。它是由 Redis Labs 开发的，提供了更高级的抽象和功能。Redisson 封装了 Redis 的底层操作，提供了一套丰富且易于使用的 Java API，支持多种 Redis 数据结构，并内置了许多高级功能，例如：
+    - 分布式锁（RedissonLock）
+    - 读写锁（RedissonReadWriteLock）
+    - 信号量（RedissonSemaphore）
+    - 可过期锁（RedissonRedLock）
+    - 分布式集合（如分布式 Set、Map、List 等）
+    - 分布式对象（如分布式 Queue、Stack 等）
+    - 支持多种序列化方式
+    - 提供了异步和反应式（Reactive）API
+      简单来说，Redis 是底层数据存储服务，而 Redisson 是一个功能强大的 Java 客户端库，简化了与 Redis 的交互，并提供了许多开箱即用的分布式解决方案。
 27. Redis中的管道有什么用？
+    答：Redis 管道（Pipeline）是一种客户端技术，允许客户端将多个 Redis 命令一次性发送给服务器，而不需要等待每个命令的响应。服务器会顺序处理这些命令，并将所有响应打包返回给客户端。
+    管道的主要作用是：
+    - **提高性能**：减少了客户端和服务器之间的网络往返次数（Round-Trip Time, RTT）。对于需要执行大量连续命令的场景，可以显著提升吞吐量。
+    - **批量处理**：将多个操作捆绑在一起执行，逻辑上更清晰。
+      例如，原本需要 10 次网络往返的 10 个命令，使用管道后可能只需要 1 次网络往返（发送所有命令）和 1 次网络往返（接收所有响应），大大减少了网络开销。
 28. Redis事务相关的命令有哪几个？
+    答：Redis 的事务主要通过以下命令实现：
+    - `MULTI`：标记一个事务块的开始。在 `MULTI` 命令之后发送的命令不会立即执行，而是被放入一个队列中。
+    - `EXEC`：执行 `MULTI` 命令之后队列中所有的命令。如果事务执行成功，所有命令都会按顺序执行；如果事务执行失败（例如某个命令语法错误），则整个事务块会被取消（discard）。
+    - `DISCARD`：取消当前正在执行的事务，清空事务队列。
+    - `WATCH`：监视一个或多个 key。如果在 `EXEC` 执行之前，被监视的 key 被其他客户端修改了，那么当前事务会以失败告终（返回空值）。常用于实现乐观锁。
+    - `UNWATCH`：取消对所有 key 的监视。
 29. Redis key的过期时间和永久有效分别怎么设置？
+    答：
+    - 设置 key 的过期时间：
+        - `EXPIRE key seconds`：为指定的 key 设置生存时间（TTL），单位是秒。例如 `EXPIRE mykey 10` 表示 mykey 10 秒后过期。
+        - `PEXPIRE key milliseconds`：同上，但单位是毫秒。
+        - `EXPIREAT key timestamp`：为 key 设置过期时间戳（Unix 时间戳，单位是秒）。例如 `EXPIREAT mykey 1712345678` 表示在指定时间戳对应的时刻过期。
+        - `PEXPIREAT key milliseconds-timestamp`：同上，但时间戳单位是毫秒。
+        - `SET key value EX seconds` (Redis 2.6+) 或 `SET key value PX milliseconds`：在设置 key 值的同时，直接指定过期时间。例如 `SET mykey "hello" EX 10`。
+    - 设置 key 永久有效：
+        - `PERSIST key`：移除指定 key 的过期时间，使其永久有效。
+        - 在 `SET` 命令中不使用 `EX` 或 `PX` 选项，直接 `SET key value` 即可设置一个永不过期的 key。
 30. Redis回收使用的是什么算法？
+    答：Redis 内存回收主要依赖于它的 **淘汰策略（Eviction Policy）**，而不是传统意义上的垃圾回收（GC）。当 Redis 实例的内存使用达到 `maxmemory` 限制时，会根据配置的淘汰策略来决定删除哪些 key 以释放内存。常见的淘汰策略包括：
+    - `noeviction`（默认）：不淘汰任何 key，当内存不足时，对于写操作（如 SET）直接返回错误（除了 SAVE 命令）。
+    - `volatile-ttl`：在设置了过期时间的 key 中，优先淘汰那些 TTL（Time To Live）值最小的 key（即最快要过期的）。
+    - `volatile-random`：在设置了过期时间的 key 中，随机淘汰一部分 key。
+    - `volatile-lru`：在设置了过期时间的 key 中，使用 LRU（Least Recently Used，最近最少使用）算法淘汰最近最少被访问的 key。
+    - `volatile-lfu`：在设置了过期时间的 key 中，使用 LFU（Least Frequently Used，最近最不常用）算法淘汰访问频率最低的 key。
+    - `allkeys-lru`：在所有的 key 中（无论是否设置了过期时间），使用 LRU 算法淘汰 key。
+    - `allkeys-random`：在所有的 key 中，随机淘汰一部分 key。
+    - `allkeys-lfu`：在所有的 key 中，使用 LFU 算法淘汰 key。
+      Redis 还会定期清理已经过期但尚未被删除的 key（通过 `expireIfNeeded` 函数在访问 key 或执行 `SAVE`/`BGSAVE` 时检查）。
 31. 一个Redis实例最多能存放多少的keys？List、Set、Sorted Set他们最多能存放多少元素？
+    答：
+    - 一个 Redis 实例理论上最多可以存储约 **2^32 个 key**（即大约 42 亿个 key）。这受限于 Redis 内部哈希表的大小和系统内存。实际上，能存储多少 key 主要取决于服务器的内存大小和配置。
+    - 对于 `List`（列表）、`Set`（集合）、`Sorted Set`（有序集合）这些数据结构：
+        - 理论上，它们的元素数量也可以达到非常大的值，主要受限于可用内存。
+        - `List`：基于双向链表或压缩列表（ziplist）实现，元素数量可以达到数亿甚至更多，具体取决于内存。
+        - `Set`：基于哈希表或整数集合（intset）实现，元素数量同样可以达到数亿。
+        - `Sorted Set`：基于压缩列表（ziplist）或跳跃表（skiplist）实现，元素数量也可以达到数亿。
+          实际能存储多少元素，同样由服务器的内存总量和 Redis 的内存淘汰策略决定。当内存不足时，会根据淘汰策略删除部分元素或 key。
 32. Redis—跳跃表，复杂度是多少？
+    答：Redis 中的跳跃表（Skip List）是一种实现有序集合（Sorted Set）的数据结构。它的平均时间复杂度为：
+    - **查找（Find/Search）**：O(log n)
+    - **插入（Insert）**：O(log n)
+    - **删除（Delete）**：O(log n)
+      其中 n 是跳跃表中的元素数量。最坏情况下时间复杂度为 O(n)，但这种情况发生的概率极低，因为跳跃表通过随机生成索引层来保证平均性能。空间复杂度大约是 O(n log n)，因为每个节点除了存储数据外，还需要存储指向不同层级的指针。
 33. Redis有哪些优缺点？为什么要用 Redis ？
+    答：
+    **优点**：
+    - **高性能**：基于内存操作，读写速度极快（通常在微秒级别）。
+    - **数据结构丰富**：支持字符串、哈希、列表、集合、有序集合等多种数据结构，满足不同场景需求。
+    - **持久化**：支持 RDB（快照）和 AOF（追加日志）两种持久化方式，可以在重启后恢复数据。
+    - **原子性操作**：支持对多个操作进行原子性处理（通过事务或特殊命令如 INCR）。
+    - **发布/订阅**：内置消息发布订阅功能。
+    - **灵活的数据过期**：支持设置 key 的过期时间。
+    - **主从复制**：支持数据备份和读写分离。
+    - **集群支持**：支持分布式部署，解决单机内存瓶颈。
+    **缺点**：
+    - **内存存储**：数据全部在内存中，内存成本较高，不适合存储海量数据。
+    - **持久化可能丢失数据**：即使有 AOF，在极端情况下（如断电且 AOF 未刷盘）仍可能丢失少量数据。RDB 则可能丢失上次快照到崩溃之间的数据。
+    - **内存限制**：受限于物理内存大小。
+    - **复杂性**：对于复杂的应用场景，配置和维护可能比较复杂（如集群管理、持久化策略选择）。
+    - **网络依赖**：作为客户端-服务器模型，网络延迟会影响性能。
+    **为什么要用 Redis**：
+    主要是因为它的 **高性能** 和 **丰富的数据结构**。当应用需要：
+    - **缓存**：减轻数据库压力，加速数据访问。
+    - **会话管理**：存储用户会话信息。
+    - **实时统计**：如排行榜、计数器、用户在线状态等。
+    - **消息队列**：实现简单的异步处理或任务队列（虽然专业消息队列如 Kafka/RabbitMQ 更强大）。
+    - **分布式锁**：在分布式环境中协调多个进程。
+    - **地理空间索引**：Redis 3.2+ 提供了 GEO 相关命令。
+    这些场景下，Redis 的内存特性和数据结构优势可以带来显著的性能提升和开发便利性。
 34. 为什么要用Redis 而不用 map/guava 做缓存?
+    答：
+    - **作用域不同**：
+        - `Map` 和 Guava Cache 是 **本地缓存**，数据只存在于当前 JVM 进程内存中。如果应用部署在多台服务器上，每台服务器都有自己的缓存副本，无法共享数据，也无法实现分布式缓存。
+        - Redis 是 **分布式缓存**，数据存储在独立的 Redis 服务器上，可以被多个应用实例共享访问。
+    - **生命周期和一致性**：
+        - Guava Cache 可以设置过期时间和大小限制，相对 `Map` 更好管理，但仍然是进程内的。应用重启或服务器宕机会导致缓存丢失。
+        - Redis 可以持久化数据到磁盘，重启后能恢复。并且可以精确控制 key 的过期时间。
+    - **功能丰富性**：
+        - Redis 提供了 `Map` 和 Guava Cache 没有的丰富数据结构（如 List, Set, Sorted Set, Hash）和原子操作，可以满足更复杂的需求。
+    - **集群和高可用**：
+        - Redis 支持主从复制和集群，可以构建高可用、高性能的缓存系统，处理大量并发请求和大数据量。Guava Cache 无法做到。
+    - **运维和管理**：
+        - Redis 是一个独立的服务，可以单独进行监控、管理、备份和扩展。Guava Cache 需要与应用程序生命周期绑定。
+          **总结**：如果只需要在单机应用内缓存数据，且对数据共享、持久化、高可用性要求不高，Guava Cache 是个不错的选择。但如果需要跨多台服务器共享缓存、需要更高的性能和可靠性、或者需要使用 Redis 特有的数据结构和功能，那么 Redis 是更合适的选择。
 35. 如何用 Redis 统计独立用户访问量？
-36. 如何选择合适的持久化方式
+    答：可以使用 Redis 的 `Set` 数据结构来统计独立用户（Unique Users, UV）访问量。Set 的特点是元素唯一，自动去重。
+    具体步骤如下：
+    1.  **定义 Key**：为每天的独立用户统计定义一个唯一的 Key，例如 `unique_visitors:2025-06-25`。
+    2.  **记录用户访问**：当有用户访问时，将用户的唯一标识（如用户 ID、Session ID 或设备 ID）作为元素，使用 `SADD` 命令添加到对应的 Set 中。
+        ```redis
+        SADD unique_visitors:2025-06-25 user123
+        SADD unique_visitors:2025-06-25 user456
+        SADD unique_visitors:2025-06-25 user123  // 重复添加，Set 会自动去重
+        ```
+    3.  **统计独立用户数**：使用 `SCARD` 命令获取 Set 中元素的数量，这个数量就是当天的独立用户访问量。
+        ```redis
+        SCARD unique_visitors:2025-06-25  // 假设返回 2，表示有 2 个独立用户
+        ```
+    4.  **设置过期时间**：为了避免 Set 永远增长占用过多内存，可以为这个 Key 设置一个合理的过期时间，比如第二天自动过期。
+        ```redis
+        EXPIRE unique_visitors:2025-06-25 86400  // 24小时后过期
+        ```
+    这种方法利用了 Set 的去重特性，简单高效。对于需要统计特定时间段（如最近7天）的独立用户，可以维护多个 Set（每天一个）并使用 `SUNION` 合并后再统计，或者使用 Redis 的 HyperLogLog 结构进行近似统计（内存占用更小，但结果不是精确值）。
+36. 如何选择合适的持久化方式？
+    答：选择 Redis 持久化方式主要取决于你的业务需求，特别是对数据安全性和性能的要求。主要有两种持久化方式：RDB（Redis Database）和 AOF（Append Only File）。
+*   **RDB (Redis Database):**
+    *   **原理:** 定期将内存中的数据集快照保存到磁盘（生成 .rdb 文件）。
+    *   **优点:**
+        *   生成紧凑的单文件，适合备份和迁移。
+        *   保存的是某个时间点的数据状态，恢复速度快。
+        *   对性能影响较小，尤其是在数据量大的情况下。
+    *   **缺点:**
+        *   两次快照之间如果 Redis 宕机，会丢失这段时间的数据。
+        *   生成快照时可能会阻塞主线程（取决于配置和 Redis 版本，新版本有改进）。
+    *   **适用场景:**
+        *   对数据丢失不敏感，可以接受几分钟到几小时的数据丢失。
+        *   需要定期备份。
+        *   需要快速恢复数据。
+*   **AOF (Append Only File):**
+    *   **原理:** 记录服务器接收到的每一个写操作命令，在服务器启动时，通过重新执行这些命令来恢复数据。
+    *   **优点:**
+        *   数据更安全，可以根据 `appendfsync` 配置实现每秒同步或每次写入同步，最多丢失 1 秒或 0 秒的数据。
+        *   即使 Redis 宕机，也只会丢失少量数据（取决于同步频率）。
+    *   **缺点:**
+        *   AOF 文件通常比 RDB 文件大。
+        *   恢复数据通常比 RDB 慢。
+        *   对性能有一定影响，尤其是在高频写入和 `appendfsync always` 配置下。
+    *   **适用场景:**
+        *   对数据安全性要求极高，不能容忍大量数据丢失。
+        *   可以接受稍慢的恢复速度和稍高的性能开销。
+*   **如何选择:**
+    *   **优先考虑 AOF:** 如果你的应用不能承受任何数据丢失，AOF 是更好的选择。通常推荐 `appendfsync everysec` 平衡安全性和性能。
+    *   **优先考虑 RDB:** 如果你能接受几分钟到几小时的数据丢失，并且更看重备份和恢复速度，RDB 是不错的选择。
+    *   **混合使用 (RDB + AOF):** 这是目前推荐的配置。结合两者的优点：使用 AOF 保证数据安全性（设置 `appendfsync everysec`），同时定期使用 RDB 进行快照备份。Redis 重启时会优先加载 AOF 文件恢复更完整的数据。
 37. Redis持久化数据和缓存怎么做扩容？
+    答：Redis 的扩容涉及到两个方面：持久化数据的扩容和作为缓存时的扩容。它们的方法有所不同。
+*   **持久化数据的扩容 (通常指数据量增长导致磁盘空间不足):**
+    *   **监控和规划:** 定期监控磁盘使用情况，预估数据增长趋势。
+    *   **增加磁盘空间:** 最直接的方法是给运行 Redis 的服务器增加磁盘容量（物理磁盘或云盘）。
+    *   **优化持久化策略:**
+        *   如果使用 RDB，可以调整 `save` 配置，减少快照频率，降低 RDB 文件大小。
+        *   如果使用 AOF，可以定期执行 `BGREWRITEAOF` 命令，压缩 AOF 文件大小。
+    *   **数据归档/冷热分离:** 将不常用的历史数据迁移到其他存储系统（如对象存储、归档数据库），只保留近期活跃数据在 Redis 中持久化。
+    *   **使用 SSD:** 如果条件允许，使用 SSD 替代 HDD 可以提高持久化性能，并可能允许更高的写入负载。
+*   **作为缓存时的扩容 (通常指需要服务更多的请求或更大的缓存容量):**
+    *   **垂直扩容 (Scale-up):** 增加单台 Redis 实例的内存和 CPU 资源。但这有物理或成本上限。
+    *   **水平扩容 (Scale-out):** 这是更常用的方法，通过增加 Redis 实例数量来分担负载和存储。主要方式有两种：
+        *   **主从复制 + 分片 (如 Redis Cluster):**
+            *   **主从复制:** 设置多个从节点，分担读压力，并作为主节点故障时的备份。但这不直接增加总缓存容量。
+            *   **Redis Cluster:** 将数据分片（Shard）存储到多个 Redis 节点。每个节点负责一部分数据。客户端或代理（如 Codis、Twemproxy）将请求路由到正确的节点。这是实现大规模缓存水平扩容的标准方案。扩容时，可以添加新的节点，然后通过resharding将部分槽位（slots）迁移到新节点。
+        *   **代理分片:** 使用代理服务器（如 Codis, Twemproxy）将客户端请求分发到后端的多个 Redis 实例。代理负责路由逻辑。扩容时，增加后端 Redis 实例并配置到代理。
+            扩容过程通常需要考虑数据迁移、服务中断时间、客户端兼容性等问题，尤其是对于在线服务。
 38. Redis key的过期时间和永久有效分别怎么设置？
+    答：这个问题和第 29 题重复了，请参考第 29 题的答案。
 39. 我们知道通过expire来设置key 的过期时间，那么对过期的数据怎么处理呢?
+    答：当 Redis 中一个 Key 的过期时间到达后，这个 Key 会被标记为过期，但它的删除并不是立即发生的。Redis 采取了惰性删除和定期删除两种策略来处理过期的 Key，具体请看下一题。处理过程大致如下：
+1.  **标记过期:** 当你使用 `EXPIRE`、`SETEX`、`LPUSH` 带过期时间等命令设置 Key 的过期时间时，Redis 内部会为这个 Key 记录一个过期时间戳。
+2.  **等待删除:** Key 到期后，它并不会立刻从内存中移除。它仍然可以被读取（读取到的可能是旧值，然后该 Key 会被删除），也可以被更新（这通常会清除它的过期标记，使其变为永久有效）。
+3.  **最终删除:** 最终，通过惰性删除或定期删除机制，这个过期的 Key 会被发现并从内存中删除，释放内存空间。
 40. Redis的过期键的删除策略
+    答：Redis 使用两种主要的策略来删除过期的 Key：
+*   **惰性删除 (Lazy Deletion):**
+    *   **原理:** 不主动删除过期的 Key。只有当客户端尝试访问（读取、写入等）一个已经过期的 Key 时，Redis 才会检查该 Key 是否过期，如果过期，就立即删除它。
+    *   **优点:** 对性能影响小，只有在需要时才做删除操作。
+    *   **缺点:** 如果一个 Key 过期了但长期不再被访问，它会一直留在内存中，直到被访问时才被删除，这可能导致内存泄漏（虽然不是真正的内存泄漏，但会浪费内存）。
+*   **定期删除 (Periodic Deletion / Active Expiration):**
+    *   **原理:** Redis 会每隔一段时间（由 `hz` 配置项控制，默认 10Hz）主动检查一次数据库中的一部分过期的 Key，并删除它们。每次检查会处理一定数量的 Key（算法内部优化）。
+    *   **优点:** 可以主动清理过期的 Key，避免内存浪费。通过控制检查的频率和范围，可以平衡 CPU 使用率和内存使用率。
+    *   **缺点:** 如果数据库中有很多过期的 Key，定期删除可能会消耗较多的 CPU 资源，影响 Redis 的响应速度。因此，Redis 限制了每次定期删除能处理的 Key 数量和执行时间。
+*   **总结:** Redis 结合使用这两种策略：定期删除负责主动清理大部分过期的 Key，而惰性删除作为补充，确保那些未被定期删除机制处理到的过期 Key 在被访问时也能被清除。这种混合策略在保证内存及时释放和系统性能之间取得了较好的平衡。
 41. Redis的内存用完了会发生什么？
+    答：当 Redis 的内存使用达到 `maxmemory` 配置的限制时，会发生以下情况：
+1.  **触发策略:** Redis 会根据配置的 `maxmemory-policy`（内存淘汰策略）来决定如何处理新数据的写入请求。
+2.  **处理新写入:**
+    *   **如果策略允许淘汰数据 (如 volatile-lru, allkeys-lru, volatile-random, allkeys-random, volatile-ttl):** Redis 会根据策略从现有数据中淘汰一部分 Key（例如，淘汰最近最少使用的 Key），然后为新数据分配空间。如果无法及时淘汰足够的数据，写入操作可能会失败（取决于配置，默认是返回错误）。
+    *   **如果策略是 noeviction (不淘汰):** 这是默认策略。当内存满时，Redis 会拒绝所有写入操作（如 SET, LPUSH 等），并返回错误（`OOM command not allowed when used memory > 'maxmemory'`）。但读取操作（如 GET）仍然可以正常进行。
+    *   **如果策略涉及过期键 (如 volatile-lru, volatile-random, volatile-ttl):** 只会淘汰设置了过期时间的 Key。
+3.  **影响:**
+    *   **写入失败:** 应用程序可能会收到写入失败的错误，需要处理这些异常。
+    *   **数据丢失风险:** 如果使用 noeviction 策略，且应用没有处理写入失败，可能导致应该写入的数据丢失。
+    *   **性能下降:** 即使没有直接拒绝写入，频繁的淘汰操作也可能影响 Redis 的性能。
+4.  **避免方法:**
+    *   合理设置 `maxmemory` 值，不要超过服务器可用内存。
+    *   根据业务需求选择合适的 `maxmemory-policy`。
+    *   优化数据结构，使用更节省内存的编码（如使用整数集合代替普通列表，使用压缩列表代替哈希表等）。
+    *   进行水平扩容（如使用 Redis Cluster）。
 42. Redis如何做内存优化？
+    答：Redis 内存优化可以从多个方面入手：
+*   **选择合适的数据结构:**
+    *   根据场景选择最节省内存的数据结构。例如，用 `SET` 代替 `LIST` 存储唯一元素，用 `HASH` 存储对象属性。
+*   **利用编码优化:**
+    *   Redis 内部会根据数据量自动选择不同的底层编码方式。了解这些编码（如 ziplist, intset, hashtable 等）的特点，可以通过配置（如 `list-max-ziplist-size`, `hash-max-ziplist-entries` 等）来强制使用更节省内存的编码，前提是业务允许。
+*   **使用更紧凑的数据类型:**
+    *   尽量使用整数而不是字符串表示数值。
+    *   使用短字符串。
+*   **合理设置 Key 和 Value 的长度:**
+    *   Key 尽量简短且具有可读性，避免过长无意义的 Key。
+    *   Value 也应尽量紧凑，避免存储冗余信息。
+*   **使用 Hash 结构存储对象:**
+    *   对于包含多个属性的对象，使用 `HASH` 存储比用多个独立的 Key 存储更节省内存（Redis 内部有优化）。
+*   **利用 Redis 4.0+ 的模块功能:**
+    *   如 `RedisBloom` 模块提供的 `CMS` (Count-Min Sketch) 和 `TFT` (Top-K) 结构，可以在占用极小内存的情况下统计频率或 Top N，远比用普通数据结构（如 Sorted Set）节省内存。
+*   **设置 Key 的过期时间:**
+    *   对于临时数据，设置合理的过期时间，让 Redis 自动清理不再需要的数据，释放内存。
+*   **选择合适的持久化策略:**
+    *   AOF 文件通常比 RDB 大，如果对数据丢失不敏感，RDB 可能更节省磁盘空间。定期重写 AOF (`BGREWRITEAOF`) 也可以减小文件大小。
+*   **使用 Redis Cluster:**
+    *   水平分片可以将数据分散到多个节点，每个节点管理的数据量减少，可以更有效地利用内存。
 43. Redis事务的三个阶段
+    答：Redis 事务的执行过程可以分为以下三个阶段：
+1.  **开始事务 (MULTI):**
+    *   客户端向 Redis 发送 `MULTI` 命令。
+    *   Redis 进入事务状态，之后客户端发送的所有命令都不会立即执行，而是被放入一个队列（命令队列）中。
+2.  **执行命令队列 (QUEUED):**
+    *   在事务状态下，客户端可以继续发送多个 Redis 命令（如 `SET`, `GET`, `INCR` 等）。
+    *   对于每个命令，Redis 不会立即执行，而是返回 `QUEUED` 表示命令已入队。
+3.  **执行事务 (EXEC):**
+    *   客户端发送 `EXEC` 命令。
+    *   Redis 开始按顺序执行命令队列中的所有命令。
+    *   执行完成后，Redis 退出事务状态，并将所有命令的执行结果依次返回给客户端。
+    *   如果在 `EXEC` 之前发送了 `DISCARD` 命令，则放弃执行队列中的所有命令，并退出事务状态。
+        简单来说就是：`MULTI` -> `QUEUED` -> `EXEC`。
 44. Redis事务相关命令
+    答：Redis 事务相关的命令主要有以下几个：
+*   **`MULTI`:** 标记一个事务块的开始。之后发送的命令都会被排队。
+*   **`EXEC`:** 执行事务块中所有被排队的命令。这是事务的提交操作。
+*   **`DISCARD`:** 取消事务，放弃执行事务块中所有被排队的命令。这是事务的回滚操作（放弃当前事务）。
+*   **`WATCH key [key ...]`:** 监视一个或多个 Key。如果在 `EXEC` 执行之前，这些 Key 被其他客户端修改了，那么当前事务会以失败告终（`EXEC` 返回空回复）。常用于实现类似乐观锁的机制。
+*   **`UNWATCH`:** 取消 `WATCH` 命令对所有 Key 的监视。如果在事务执行前调用，则清除所有监视，事务将不会因为 Key 被修改而失败。
 45. Redis事务保证原子性吗，支持回滚吗？
+    答：
+*   **原子性:**
+    *   Redis 事务**部分保证原子性**。它保证了队列中的命令要么都执行，要么都不执行（在 `EXEC` 命令成功执行的情况下）。也就是说，事务内的命令序列是作为一个整体执行的，不会被其他客户端的命令打断。
+    *   **但是**，它不保证事务中的命令**不会因为错误而中断**。如果事务中的某个命令因为语法错误（比如命令写错了）而无法执行，那么在 `EXEC` 时，整个事务都会被取消，不会执行任何命令。但如果命令本身是正确的，只是因为运行时错误（比如对一个不存在的 Key 执行了某些操作）导致失败，其他命令仍然会继续执行。这与数据库的原子性（所有操作要么全部成功，要么全部失败，且失败时所有已执行的操作都要回滚）有所不同。
+*   **回滚:**
+    *   Redis 事务**不支持传统数据库意义上的回滚**。一旦某个命令在事务中执行失败了（不是因为语法错误导致整个事务取消），Redis 不会自动撤销之前已经执行成功的命令。它只会继续执行队列中剩余的命令。
+    *   唯一的“回滚”机制是 `DISCARD` 命令，它可以放弃当前整个事务块，不执行任何命令。另外，如果被 `WATCH` 的 Key 在 `EXEC` 前被修改，事务也会失败（`EXEC` 返回空），但这并不是针对事务内命令执行错误的回滚。
+        总结：Redis 事务提供了一种将多个命令打包执行的方式，保证了命令执行的顺序性和整体性（要么全执行，要么全不执行，除非有语法错误），但不保证每个命令执行成功的原子性，也不支持在命令执行失败后回滚整个事务。对于需要严格 ACID 特性的复杂操作，通常需要结合 Lua 脚本或其他外部机制来实现。
 46. Redis事务支持隔离性吗？
+    不支持。Redis 事务中的命令在执行前不会加锁，其他客户端可以并发执行命令，可能导致脏读或不可重复读。
 47. Redis集群的主从复制模型是怎样的？
+    主从复制模型是主从模式的，主节点负责处理写操作和读操作，从节点只负责复制主节点的数据，处理读操作。
 48. 生产环境中的 redis 是怎么部署的？
+    生产环境中通常采用 Redis 集群模式部署，包括主从复制和分片，以提高可用性和扩展性。
 49. 说说Redis哈希槽的概念
+    Redis 集群将整个数据集划分为 16384 个哈希槽，每个键根据其 CRC16 值对 16384 取模来确定属于哪个槽，槽再映射到具体节点。
 50. Redis集群会有写操作丢失吗？为什么？
+    会有。因为主节点通常采用异步复制方式将数据同步到从节点，如果主节点在数据同步完成前发生故障，可能导致部分写操作丢失。
 51. Redis集群最大节点个数是多少？
+    Redis集群最大节点个数是 1000 个。
 52. Redis集群如何选择数据库？
+    Redis集群不支持选择数据库，所有键都存储在同一个数据库中。
 53. Redis是单线程的，如何提高多核CPU的利用率？
+    可以通过在多核服务器上运行多个 Redis 实例来提高多核 CPU 的利用率。
 54. 为什么要做Redis分区？有什么缺点？
+    做分区是为了支持更大的数据集和更高的并发量。缺点包括：增加了系统复杂性，可能导致数据倾斜，以及跨分区操作效率降低。
 55. 你知道有哪些Redis分区实现方案？
+    常见的 Redis 分区实现方案包括：客户端分区、代理分区（如 Twemproxy）、以及 Redis 自身的集群模式。
 56. 缓存的实现原理，设计缓存要注意什么
+    实现原理：缓存通常位于应用与数据源（如数据库）之间，通过将频繁访问的数据或计算结果存储在内存中，以快速响应后续请求，减少对数据源的访问压力。设计上一般包括缓存键、缓存值、过期时间、缓存策略（如 LRU）等。
+    设计注意：缓存穿透（频繁查询不存在的Key）、缓存雪崩（大量Key同时过期）、缓存击穿（热点Key失效瞬间大量请求打向数据源）、缓存与数据库一致性、Key设计、过期策略、容量规划、高可用等。
 57. 如何解决 Redis 的并发竞争 Key 问题
+    可以使用 Redis 的事务（MULTI/EXEC）或 Lua 脚本。Lua 脚本在 Redis 中是原子执行的，能更好地保证多个 Redis 操作作为一个整体不被打断。另一种方式是使用 SETNX（或 SET with NX option）配合重试机制实现简单的分布式锁。
 58. 分布式Redis是前期做还是后期规模上来了再做好？为什么？
+    建议前期就考虑并设计分布式 Redis 方案。因为从单机迁移到分布式涉及数据迁移、架构调整、客户端改造等复杂工作，后期规模上来再改造成本和风险会非常高。提前规划可以更好地支持业务增长，避免性能瓶颈。
 59. 什么是 RedLock？
+    RedLock 是一种分布式锁算法，旨在解决在多个 Redis 实例上实现更可靠、更安全的分布式锁的问题。它通过在多个独立的 Redis 实例上获取锁，并验证大多数实例是否成功获取锁来提高锁的安全性，防止单点故障或网络分区导致的锁失效。
 60. Redis支持的Java客户端都有哪些？官方推荐用哪个？
+    常见的 Java 客户端有 Jedis、Lettuce、Redisson 等。官方没有明确指定唯一推荐，但 Lettuce 和 Redisson 因其高性能、支持连接池、异步操作、反应式编程（Lettuce）以及高级特性（Redisson）而备受推荐。Lettuce 因其 Netty 底层和更好的连接管理和协议支持，在许多场景下是更现代的选择。
 61. 为什么Redis的操作是原子性的，怎么保证原子性
+    Redis 的单条命令是原子性的，因为它的命令执行模型是单线程的（处理命令的线程只有一个）。命令会顺序执行，一个命令执行完成前，不会执行下一个命令。事务（MULTI/EXEC）通过将多个命令打包，保证这些命令作为一个整体原子性地执行。Lua 脚本通过在 Redis 中被原子化执行来保证脚本内所有操作的原子性。
 62. Redis常见性能问题和解决方案？
+    常见问题：网络延迟、内存不足、CPU 瓶颈、大量 Key 过期导致 CPU 飙升、大 Key/Hot Key 问题、持久化影响性能等。
+    解决方案：优化网络配置、合理规划内存（使用合适的数据结构、压缩、淘汰策略）、监控 CPU 使用、设置合理的 Key 过期策略、使用 SCAN 命令渐进式处理大 Key 集合、避免产生超大 Key、使用 Pipeline 减少 RTT、优化持久化配置（如 AOF 重写）、使用集群分散压力、监控热点 Key 并做缓存等。
 63. 一个字符串类型的值能存储最大容量是多少？
+    一个字符串类型的值最大可以存储 512 MB 的数据。
 64. Redis如何做大量数据插入？
+    可以使用 Redis 的管道（Pipeline）技术，将多个命令打包一次性发送给 Redis 服务器，减少网络往返时间（RTT）。对于非常大的数据集，可以考虑使用 Redis 的 RDB 快照原理，通过 `redis-cli --pipe` 或专门的导入工具（如 `redis-benchmark` 模拟，或自定义脚本配合 Pipeline）。
 65. 假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？
+    可以使用 `SCAN` 命令配合通配符模式。例如，如果前缀是 `user:12345:history:`，可以执行 `SCAN cursor MATCH user:12345:history:* COUNT num`。`SCAN` 命令是渐进式的，可以避免像 `KEYS` 命令那样阻塞整个 Redis 服务器，`MATCH` 参数用于匹配特定模式的 Key，`COUNT` 参数建议设置一个较大的值（如 1000 或更高）来提高遍历效率。需要循环调用 `SCAN` 直到游标 `cursor` 返回 0。
 66. 使用Redis做过异步队列吗，是如何实现的？
+    可以使用 LPUSH 命令将任务推入列表，BRPOP 命令阻塞式地取出任务。
 67. Redis如何实现延时队列？
+    可以使用 ZSET，将任务和过期时间作为score，到期后通过 ZRANGEBYSCORE 取出。
 68. Redis回收进程如何工作的？
+    通过淘汰策略（如 LRU、TTL）在内存不足时自动删除部分键值对。
 69. 热点数据和冷数据是什么
-70. 使用过Redis哪些命令？
\ No newline at end of file
+    热点数据是访问频率高的数据，冷数据是访问频率低的数据。
+70. 使用过Redis哪些命令？
+    如 SET、GET、DEL、LPUSH、RPUSH、LPOP、RPOP、LPUSHX、RPUSHX、EXPIRE、TTL、HSET、HGET、SADD、SREM、SMEMBERS、ZADD、ZRANGE、ZRANK、ZREM、SCAN 等。
\ No newline at end of file

From 831ce5a9b6696ed745b380acae14bad6ee81f0de Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Wed, 25 Jun 2025 15:42:08 +0800
Subject: [PATCH 5/9] =?UTF-8?q?=E8=A1=A5=E5=85=85=E7=AD=94=E6=A1=88?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...74\217\351\235\242\350\257\225\351\242\230.md" | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\345\210\206\345\270\203\345\274\217/\345\210\206\345\270\203\345\274\217\351\235\242\350\257\225\351\242\230.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\345\210\206\345\270\203\345\274\217/\345\210\206\345\270\203\345\274\217\351\235\242\350\257\225\351\242\230.md"
index afc09b8..9800386 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\345\210\206\345\270\203\345\274\217/\345\210\206\345\270\203\345\274\217\351\235\242\350\257\225\351\242\230.md"
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\345\210\206\345\270\203\345\274\217/\345\210\206\345\270\203\345\274\217\351\235\242\350\257\225\351\242\230.md"
@@ -1,11 +1,24 @@
-### 分布式 
+### 分布式
+
+好的，以下是按顺序回答的问题及输出结果：
+
 1. 说说分布式事务？分布式事务的解决方案
+   答：分布式事务是指涉及多个独立服务或数据库的事务，这些服务或数据库可能位于不同的物理位置。分布式事务的解决方案包括两阶段提交（2PC）、三阶段提交（3PC）、补偿事务（TCC）、本地消息表、消息队列事务等。
 2. 什么是分布式系统？
+   答：分布式系统是指由多个独立计算机组成的系统，这些计算机通过网络相互通信和协调，共同完成特定的任务。分布式系统的特点是高可用性、可扩展性和容错性。
 3. 讲讲CAP理念。
+   答：CAP理念是指在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三个属性只能同时满足其中两个。一致性是指所有节点在同一时间看到的数据是一致的；可用性是指每个请求都能得到响应；分区容错性是指系统在遇到网络分区时仍能继续运行。
 4. 怎么理解强一致性、单调一致性和最终一致性？
+   答：强一致性是指所有节点在同一时间看到的数据是一致的，任何一次读都能保证读到最新的写；单调一致性是指如果节点读取到某个数据项的值，后续读取该数据项的值不会比之前读取的值更旧；最终一致性是指系统在经过一段时间后，所有节点最终会达到一致的状态，但不保证在任意时刻所有节点都一致。
 5. 如何实现分布式锁？
+   答：分布式锁可以通过多种方式实现，常见的有基于数据库的锁、基于Redis的锁、基于Zookeeper的锁等。基于Redis的锁通常使用SETNX命令实现，基于Zookeeper的锁通常使用临时顺序节点实现。
 6. 如何实现分布式 Session?
+   答：分布式Session可以通过多种方式实现，常见的有基于数据库的Session共享、基于Redis的Session共享、基于Nginx的Session sticky等。基于Redis的Session共享是将Session数据存储在Redis中，所有服务节点共享同一个Redis实例。
 7. 负载均衡的理解？
+   答：负载均衡是指将网络流量或计算任务均匀地分配到多个服务器上，以提高系统的性能、可靠性和可扩展性。负载均衡可以通过硬件设备（如F5）或软件（如Nginx、HAProxy）实现。
 8. 分布式集群下如何做到唯一序列号？
+   答：在分布式集群下生成唯一序列号可以通过多种方式实现，常见的有UUID、Snowflake算法、数据库自增ID、Redis原子操作等。Snowflake算法是一种分布式ID生成算法，结合了时间戳、机器ID和序列号生成唯一ID。
 9. 分布式事务
+   答：分布式事务是指涉及多个独立服务或数据库的事务，这些服务或数据库可能位于不同的物理位置。分布式事务的解决方案包括两阶段提交（2PC）、三阶段提交（3PC）、补偿事务（TCC）、本地消息表、消息队列事务等。
 10. 什么是一致性hash。
+    答：一致性哈希是一种特殊的哈希算法，用于在分布式系统中将数据均匀地分布到多个节点上。一致性哈希通过将数据和节点映射到一个环形哈希空间，使得在节点增减时，只有部分数据需要重新分布，从而减少数据迁移的开销。

From 52bc0836cdc407c702ce7721b080be0a7dac6eb9 Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Wed, 25 Jun 2025 15:42:34 +0800
Subject: [PATCH 6/9] =?UTF-8?q?=E8=A1=A5=E5=85=85=E7=AD=94=E6=A1=88?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...37\351\235\242\350\257\225\351\242\230.md" | 44 ++++++++++++++-----
 1 file changed, 33 insertions(+), 11 deletions(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\346\223\215\344\275\234\347\263\273\347\273\237/\346\223\215\344\275\234\347\263\273\347\273\237\351\235\242\350\257\225\351\242\230.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\346\223\215\344\275\234\347\263\273\347\273\237/\346\223\215\344\275\234\347\263\273\347\273\237\351\235\242\350\257\225\351\242\230.md"
index f854380..1535849 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\346\223\215\344\275\234\347\263\273\347\273\237/\346\223\215\344\275\234\347\263\273\347\273\237\351\235\242\350\257\225\351\242\230.md"
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\346\223\215\344\275\234\347\263\273\347\273\237/\346\223\215\344\275\234\347\263\273\347\273\237\351\235\242\350\257\225\351\242\230.md"
@@ -1,22 +1,44 @@
 ### 操作系统
 1. Linux系统下你关注过哪些内核参数，说说你知道的。
+答：我关注过的一些内核参数包括net.core.somaxconn、net.ipv4.tcp_tw_reuse、vm.swappiness等。net.core.somaxconn用于控制监听队列的最大长度，net.ipv4.tcp_tw_reuse用于控制TIME_WAIT状态的套接字是否可以被重用，vm.swappiness用于控制内核使用交换空间的倾向。
 2. epoll和poll有什么区别。
+答：epoll和poll都是I/O多路复用机制，但epoll在处理大量文件描述符时效率更高。poll使用轮询方式检查文件描述符的状态，而epoll使用事件驱动机制，只返回发生变化的文件描述符。此外，epoll支持边缘触发（ET）和水平触发（LT）两种模式，而poll只支持水平触发。
 3. 线上CPU爆高，请问你如何找到问题所在。
+答：首先，我会使用top命令查看CPU使用率高的进程，然后使用ps命令进一步查看该进程的详细信息。接着，我会使用strace或gdb工具跟踪该进程的系统调用或执行状态，找出导致CPU高负载的具体原因。
 4. Linux下IO模型有几种，各自的含义是什么。
+答：Linux下IO模型有五种，分别是阻塞IO、非阻塞IO、IO多路复用、信号驱动IO和异步IO。阻塞IO会阻塞进程直到数据准备好；非阻塞IO会立即返回一个错误码，进程需要轮询检查数据是否就绪；IO多路复用使用select/poll/epoll等系统调用监听多个文件描述符；信号驱动IO通过信号通知进程数据就绪；异步IO由内核完成数据读写，进程无需等待。
 5. top 命令之后有哪些内容，有什么作用。
+答：top命令显示的内容包括进程ID（PID）、用户（USER）、CPU使用率（%CPU）、内存使用率（%MEM）、虚拟内存使用量（VSZ）、常驻内存使用量（RSS）、命令行（COMMAND）等。这些信息用于监控系统中各个进程的资源使用情况，帮助识别资源消耗大的进程。
 6. 进程通信有几种方式？
-7. 说说进程的调度算法
-8. 常见的几种内存管理机制
+答：进程通信的方式包括管道（Pipe）、命名管道（Named Pipe）、消息队列（Message Queue）、共享内存（Shared Memory）、信号量（Semaphore）、套接字（Socket）等。
+7. 说说进程的调度算法。
+答：进程的调度算法包括先来先服务（FCFS）、短作业优先（SJF）、优先级调度、时间片轮转（RR）、多级反馈队列调度等。FCFS按进程到达顺序调度；SJF选择执行时间最短的进程；优先级调度根据进程优先级调度；RR按时间片轮流调度；多级反馈队列结合优先级和时间片轮转。
+8. 常见的几种内存管理机制。
+答：常见的内存管理机制包括分页（Paging）、分段（Segmentation）、段页式（Segmented Paging）、虚拟内存（Virtual Memory）等。分页将内存划分为固定大小的页；分段将内存划分为逻辑段；段页式结合分段和分页；虚拟内存允许进程使用比物理内存更大的地址空间。
 9. 什么是虚拟内存(Virtual Memory)?
-10. 内存置换算法
+答：虚拟内存是一种内存管理技术，允许操作系统将硬盘空间作为内存使用，为每个进程提供独立的、连续的地址空间。虚拟内存使得进程可以访问比物理内存更大的地址空间，并通过分页机制实现物理内存和硬盘之间的数据交换。
+10. 内存置换算法。
+答：内存置换算法包括最佳置换（OPT）、先进先出（FIFO）、最近最少使用（LRU）、最不经常使用（LFU）等。OPT选择未来最久不会使用的页面置换；FIFO选择最早进入内存的页面置换；LRU选择最近最少使用的页面置换；LFU选择访问次数最少的页面置换。
 11. 虚拟地址、逻辑地址、线性地址、物理地址的区别。
-12. 操作系统的页式存储
-13. 进程和线程的区别
-14. socket客户端和服务端通信过程
+答：虚拟地址是进程使用的地址，逻辑地址是程序中的地址，线性地址是经过段式映射后的地址，物理地址是内存中的实际地址。虚拟地址通过页表映射到线性地址，再通过页表映射到物理地址。
+12. 操作系统的页式存储。
+答：页式存储是一种内存管理方式，将内存划分为固定大小的页框，进程地址空间划分为大小相同的页。通过页表将虚拟页映射到物理页框，实现虚拟内存和物理内存之间的数据交换。
+13. 进程和线程的区别。
+答：进程是资源分配的基本单位，拥有独立的地址空间和系统资源；线程是CPU调度的基本单位，共享进程的资源。进程间切换开销大，线程间切换开销小；进程间通信需要通过IPC机制，线程间可以直接共享内存。
+14. socket客户端和服务端通信过程。
+答：socket客户端和服务端通信过程包括：服务端创建socket并绑定地址，监听连接请求；客户端创建socket并连接服务端；服务端接受连接，建立通信；双方通过send/recv等函数发送和接收数据；通信结束后关闭socket。
 15. 影响调度程序的指标是什么？
+答：影响调度程序的指标包括响应时间、周转时间、等待时间、吞吐量等。响应时间是从请求到首次响应的时间；周转时间是进程从提交到完成的时间；等待时间是进程在就绪队列中的时间；吞吐量是单位时间内完成的进程数。
 16. 进程间状态有哪些？
-17.  一个线程在内存中如何存储？
-18.  僵尸进程是什么，如果产生一个僵尸进程，如何查找僵尸进程
-19.  一个进程有20个线程，在某个线程中调用fork，新的进程会有20个线程吗？
-20.  什么是 RR 调度算法？
-21.  什么是 DMA（直接内存访问）？
+答：进程间状态包括新建（New）、就绪（Ready）、运行（Running）、等待（Waiting）、终止（Terminated）等。新建是进程创建时的状态；就绪是等待CPU调度的状态；运行是进程占用CPU执行的状态；等待是进程等待某事件的状态；终止是进程执行完毕的状态。
+17. 一个线程在内存中如何存储？
+答：一个线程在内存中存储包括线程控制块（TCB）、栈、寄存器等。TCB包含线程的状态、优先级、栈指针等信息；栈用于存储线程的局部变量和函数调用信息；寄存器用于存储线程的执行状态。
+18. 僵尸进程是什么，如果产生一个僵尸进程，如何查找僵尸进程。
+答：僵尸进程是已经终止但父进程尚未回收其资源（进程描述符和退出状态）的进程。查找僵尸进程可以使用ps命令，查看状态为Z的进程。可以使用wait系统调用或kill命令回收僵尸进程。
+19. 一个进程有20个线程，在某个线程中调用fork，新的进程会有20个线程吗？
+答：不会。在Linux中，fork系统调用会复制父进程的地址空间，但不会复制线程。新的进程只有一个线程，即调用fork的线程。
+20. 什么是 RR 调度算法？
+答：RR（Round Robin）调度算法是一种时间片轮转调度算法，将CPU时间划分为时间片，轮流分配给各个进程。每个进程执行一个时间片后，调度程序会选择下一个进程执行，直到所有进程都执行完毕。
+21. 什么是 DMA（直接内存访问）？
+答：DMA（Direct Memory Access）是一种允许I/O设备直接访问系统内存的技术，无需CPU干预。DMA控制器负责管理数据传输，提高系统的I/O性能和效率。
+

From 97eac1e178d8ec96e243a3929c2fd26c246627d0 Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Wed, 25 Jun 2025 15:47:30 +0800
Subject: [PATCH 7/9] =?UTF-8?q?=E6=A0=BC=E5=BC=8F=E5=8C=96?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../README.MD"                                | 11 +++++---
 ...10\350\277\231\344\271\210\345\277\253.md" | 25 ++++++-------------
 2 files changed, 14 insertions(+), 22 deletions(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/README.MD" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/README.MD"
index 7397d39..84f495a 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/README.MD"
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/README.MD"
@@ -2,6 +2,7 @@
 
 关注公众号：捡田螺的小男孩
 ​
+
 - [oppo后端16连问](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247498750&amp;idx=1&amp;sn=19fe8b4fff28fe81db14e733053bbc74&amp;chksm=cf2224d7f855adc1d0984980a4e3de31fe33329164a472ca8d8255a8a80b69b2e23850811323&token=2001057130&lang=zh_CN#rd)
 - [小厂后端十连问（附答案）](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247498316&amp;idx=1&amp;sn=7749b78293b7b2af51eda99844e08a56&amp;chksm=cf222565f855ac7324232e2af459f8b6e6eb5fd5b272c2b29bda08cc579421b6704a0de94b2e&token=2001057130&lang=zh_CN#rd)
 - [腾讯云后端15连问！](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247498171&amp;idx=1&amp;sn=f5a7ec25a569822be0f73fbcd413e8ba&amp;chksm=cf222692f855af84fba419166fcd4235c0e78af3a2e1ec4c723a4efb1bd1ad6f8a5b9404c599&token=2001057130&lang=zh_CN#rd)
@@ -10,9 +11,11 @@
 - [面试必备：虾皮服务端15连问](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247497256&amp;idx=1&amp;sn=3b799c2d514aa25e85a6faa60d639a0b&amp;chksm=cf222901f855a017b73356b99b830b8800a7a9172fab891c5759d8dd69a270872ea9480c0b7c&token=2001057130&lang=zh_CN#rd)
 - [宇宙条一面：十道经典面试题解析](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247495342&amp;idx=1&amp;sn=54e1c0c16a6467001524c34818025331&amp;chksm=cf223187f855b89140db5ca429e6efc19d0111abf7f36b78a0ecd73b00fded1ff1e7ba32a6f1&token=2001057130&lang=zh_CN#rd)
 - [蚂蚁金服一面：十道经典面试题解析](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247493270&amp;idx=1&amp;sn=1c78a81d6e1bd0f0fd947fe8c3a33e32&amp;chksm=cf2239bff855b0a9627855f20a17799e0506eb7548a409bfa0ee0450328d7519ec70f7b962cc&token=2001057130&lang=zh_CN#rd)
-​
-## 2. 必考经典面试题
-​
+  ​
+  
+  ## 2. 必考经典面试题
+  
+  ​
 - [Redis主从、哨兵、 Cluster集群一锅端！](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247498254&amp;idx=1&amp;sn=6489360c3b226df9811e66cb40ec7656&amp;chksm=cf222527f855ac3112628bcec7730064fee3fdbe869fbd0a7410c22766a0c036a7e5c1a69fa0&token=2001057130&lang=zh_CN#rd)
 - [我们为什么要分库分表？](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247498625&amp;idx=1&amp;sn=0d7bd9d1b46eeff4c715a6761355e9b0&amp;chksm=cf2224a8f855adbea8931c8e011711f6c70cffeef8ddf8b87729c710eacef11b46eef80fda36&token=2001057130&lang=zh_CN#rd)
 - [面试必备：聊聊MySQL的主从](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247497982&amp;idx=1&amp;sn=bb589329cceb5462fc41f66ec63dbf56&amp;chksm=cf2227d7f855aec16dd4d3b3425c0401850eeaf2c9cdc82e82722d38a00c24ee9ccfa3353774&token=2001057130&lang=zh_CN#rd)
@@ -22,7 +25,7 @@
 - [看一遍就理解：IO模型详解](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247496448&amp;idx=1&amp;sn=cd502f850290a25949dd4a11ac55a039&amp;chksm=cf222c29f855a53f094bde2868900fa252b07385e73564e9ee9f0510cb4e74387d9d23ab67e6&token=2001057130&lang=zh_CN#rd)
 - [看一遍就理解：MVCC原理详解](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&amp;mid=2247495277&amp;idx=1&amp;sn=a1812febb4246f824ce54d778f672025&amp;chksm=cf223144f855b8528ad6cce707dc3a1b4d387817bd751dfab4f79dda90c6640f9763d25f3f33&token=2001057130&lang=zh_CN#rd)
 - [2W字！详解20道Redis经典面试题！（珍藏版）](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247494124&idx=1&sn=c185f7d999d5f006608d05707a8a7eea&chksm=cf2236c5f855bfd329c6e2ee27f23f8131ebcd312960190a10f1a819d67f07a21a08ad17f263&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
--  [七种方案！探讨Redis分布式锁的正确使用姿势](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247488142&idx=1&sn=79a304efae7a814b6f71bbbc53810c0c&chksm=cf21cda7f85644b11ff80323defb90193bc1780b45c1c6081f00da85d665fd9eb32cc934b5cf&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
+- [七种方案！探讨Redis分布式锁的正确使用姿势](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247488142&idx=1&sn=79a304efae7a814b6f71bbbc53810c0c&chksm=cf21cda7f85644b11ff80323defb90193bc1780b45c1c6081f00da85d665fd9eb32cc934b5cf&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
 - [面试必备！TCP协议经典十五连问！](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247490868&idx=1&sn=96889bfe6a97f9200fa2d682cf2f5d89&chksm=cf21c21df8564b0b0757df584560a69340b1775fe1c70b867439565969ec3aed19c442ff4eeb&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
 - [2W字！梳理50道经典计算机网络面试题（收藏版）](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247492832&idx=1&sn=601fa1c340a313bc0f74bb75cdb6a95a&chksm=cf223bc9f855b2dfb8d0e74f3360e2edfe25c3a728fe17e9e80b6022340994fd9d9e1ca83ca8&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
 - [ZooKeeper的十二连问，你顶得了嘛？](https://mp.weixin.qq.com/s?__biz=Mzg3NzU5NTIwNg==&mid=2247488047&idx=1&sn=4913c7e1c3b8835f7512d8dc6b845727&chksm=cf21cd06f8564410cce6121230256facb1ab3b5a9ed35579896f428d84bdea7b86836109d575&token=162724582&lang=zh_CN&scene=21#wechat_redirect)
diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md"
index a3f6b30..4aa27e8 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md"
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/\347\274\223\345\255\230,Redis/Redis\344\270\272\344\273\200\344\271\210\350\277\231\344\271\210\345\277\253.md"
@@ -1,11 +1,9 @@
-
 ## 前言
 
 大家好呀，我是捡田螺的小男孩。我们都知道Redis很快，它QPS可达10万（每秒请求数）。**Redis为什么这么快呢**,本文将跟大家一起学习。
 
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3880491879ed4a228d8f4213d987f6a3~tplv-k3u1fbpfcp-zoom-1.image)
 
-
 - 公众号：**捡田螺的小男孩**
 - [github地址](https://github.com/whx123/JavaHome)，感谢每一颗star
 
@@ -19,13 +17,10 @@
 
 我们知道，MySQL索引为了提高效率，选择了B+树的数据结构。其实合理的数据结构，就是可以让你的应用/程序更快。先看下Redis的数据结构&内部编码图：
 
-
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4ddd7723cc0e4953b746b13db7a5cea3~tplv-k3u1fbpfcp-zoom-1.image)
 
-
 ### SDS简单动态字符串
 
-
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0e68a18c50f149dda136fc9b1aa73ab8~tplv-k3u1fbpfcp-zoom-1.image)
 
 ```
@@ -33,13 +28,12 @@ struct sdshdr { //SDS简单动态字符串
     int len;    //记录buf中已使用的空间
     int free;   // buf中空闲空间长度
     char buf[]; //存储的实际内容
-}
-```
 
+```
 
 #### 字符串长度处理
 
-在C语言中，要获取```捡田螺的小男孩```这个字符串的长度，需要从头开始遍历，复杂度为O（n）;
+在C语言中，要获取这个字符串的长度，需要从头开始遍历，复杂度为O（n）;
 在Redis中， 已经有一个**len**字段记录当前字符串的长度啦，直接获取即可，时间复杂度为O(1)。
 
 #### 减少内存重新分配的次数
@@ -66,6 +60,7 @@ Redis 作为一个K-V的内存数据库，它使用用一张全局的哈希来
 哈希表查找速率很快的，有点类似于Java中的**HashMap**，它让我们在**O(1)** 的时间复杂度快速找到键值对。首先通过key计算哈希值，找到对应的哈希桶位置，然后定位到entry，在entry找到对应的数据。
 
 有些小伙伴可能会有疑问：你往哈希表中写入大量数据时，不是会遇到**哈希冲突**问题嘛，那效率就会降下来啦。
+
 > **哈希冲突：** 通过不同的key，计算出一样的哈希值，导致落在同一个哈希桶中。
 
 Redis为了解决哈希冲突，采用了**链式哈希**。链式哈希是指同一个哈希桶中，多个元素用一个链表来保存，它们之间依次用指针连接。
@@ -85,12 +80,10 @@ Redis为了解决哈希冲突，采用了**链式哈希**。链式哈希是指
 - 每一层都有一条有序的链表，最底层的链表包含了所有的元素。
 - 跳跃表支持平均 O（logN）,最坏 O（N）复杂度的节点查找，还可以通过顺序性操作批量处理节点。
 
-
 #### 压缩列表ziplist
 
 压缩列表ziplist是列表键和字典键的的底层实现之一。它是由一系列特殊编码的内存块构成的列表， 一个ziplist可以包含多个entry， 每个entry可以保存一个长度受限的字符数组或者整数，如下：
 
-
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4ce3da7cddbe4e6e94a775151664ed93~tplv-k3u1fbpfcp-zoom-1.image)
 
 - zlbytes ：记录整个压缩列表占用的内存字节数
@@ -101,14 +94,13 @@ Redis为了解决哈希冲突，采用了**链式哈希**。链式哈希是指
 
 由于内存是**连续分配**的，所以遍历速度很快。。
 
-
-##  合理的数据编码
+## 合理的数据编码
 
 Redis支持多种数据基本类型，每种基本类型对应不同的数据结构，每种数据结构对应不一样的编码。为了提高性能，Redis设计者总结出，数据结构最适合的编码搭配。
 
 Redis是使用对象（redisObject）来表示数据库中的键值，当我们在 Redis 中创建一个键值对时，至少创建两个对象，一个对象是用做键值对的键对象，另一个是键值对的值对象。
+
 ```
-//关注公众号：捡田螺的小男孩
 typedef struct redisObject{
     //类型
    unsigned type:4;
@@ -130,7 +122,6 @@ redisObject中，**type** 对应的是对象类型，包含String对象、List
 
 ## 合理的线程模型
 
-
 ### 单线程模型：避免了上下文切换
 
 Redis是单线程的，其实是指**Redis的网络IO和键值对读写**是由一个线程来完成的。但Redis的其他功能，比如持久化、异步删除、集群数据同步等等，实际是由额外的线程执行的。
@@ -148,15 +139,14 @@ Redis的单线程模型，避免了**CPU不必要的上下文切换**和**竞争
 ### I/O 多路复用
 
 什么是I/O多路复用？
+
 - I/O ：网络 I/O
 - 多路 ：多个网络连接
 - 复用：复用同一个线程。
 - IO多路复用其实就是一种同步IO模型，它实现了一个线程可以监视多个文件句柄；一旦某个文件句柄就绪，就能够通知应用程序进行相应的读写操作；而没有文件句柄就绪时,就会阻塞应用程序，交出cpu。
- 
 
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/07838d0a48ef4b38acccb7b52e5435e1~tplv-k3u1fbpfcp-zoom-1.image)
 
-
 > 多路I/O复用技术可以让单个线程高效的处理多个连接请求，而Redis使用用epoll作为I/O多路复用技术的实现。并且Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。
 
 ## 虚拟内存机制
@@ -164,6 +154,7 @@ Redis的单线程模型，避免了**CPU不必要的上下文切换**和**竞争
 Redis直接自己构建了VM机制 ，不会像一般的系统会调用系统函数处理，会浪费一定的时间去移动和请求。
 
 **Redis的虚拟内存机制是啥呢？** 
+
 > 虚拟内存机制就是暂时把不经常访问的数据(冷数据)从内存交换到磁盘中，从而腾出宝贵的内存空间用于其它需要访问的数据(热数据)。通过VM功能可以实现冷热数据分离，使热数据仍在内存中、冷数据保存到磁盘。这样就可以避免因为内存不足而造成访问速度下降的问题。
 
 ### 参考与感谢
@@ -171,5 +162,3 @@ Redis直接自己构建了VM机制 ，不会像一般的系统会调用系统函
 - [Redis之VM机制](https://www.codenong.com/cs106843764/)
 - [一文揭秘单线程的Redis为什么这么快?](https://zhuanlan.zhihu.com/p/57089960)
 - [洞察|Redis是单线程的，但Redis为什么这么快？](https://zhuanlan.zhihu.com/p/42272979)
-
-

From 5ba29d316a683cd2f9fa0dec315962beb6f9da71 Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Wed, 25 Jun 2025 16:04:18 +0800
Subject: [PATCH 8/9] =?UTF-8?q?=E8=A1=A5=E5=85=85=E7=AD=94=E6=A1=88?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...is\351\235\242\350\257\225\351\242\230.md" | 40 ++++++++++++++-----
 1 file changed, 30 insertions(+), 10 deletions(-)

diff --git "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/mybatis/mybatis\351\235\242\350\257\225\351\242\230/mybatis\351\235\242\350\257\225\351\242\230.md" "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/mybatis/mybatis\351\235\242\350\257\225\351\242\230/mybatis\351\235\242\350\257\225\351\242\230.md"
index 23b5ef7..2afe9c1 100644
--- "a/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/mybatis/mybatis\351\235\242\350\257\225\351\242\230/mybatis\351\235\242\350\257\225\351\242\230.md"
+++ "b/Java\351\235\242\350\257\225\351\242\230\351\233\206\347\273\223\345\217\267/mybatis/mybatis\351\235\242\350\257\225\351\242\230/mybatis\351\235\242\350\257\225\351\242\230.md"
@@ -1,21 +1,41 @@
 ### mybatis
-1. mybatis 中 #{}和 ${}的区别是什么？
-2. 什么是SQL注入 ，如何避免。
-3. 说一下 mybatis 的一级缓存和二级缓存
-4. mybatis 是否支持延迟加载？延迟加载的原理是什么？
-5. mybatis 动态sql中使用<where>标签与直接写where关键字有什么区别？
-6. mybatis 动态sql标签中循环标签中有哪些属性，各自的作用。
-7. mybatis 和 hibernate 的区别有哪些？
-8. RowBounds是一次性查询全部结果吗？为什么？
-9. MyBatis 定义的接口，怎么找到实现的？
+1.  mybatis 中 #{}和 ${}的区别是什么？
+    #{}是预编译占位符，会进行类型转换和SQL注入防护；${}是字符串替换，直接拼接SQL，有SQL注入风险。
+2.  什么是SQL注入 ，如何避免。
+    SQL注入是攻击者通过拼接SQL语句来执行恶意代码。避免方法：使用预编译语句（如MyBatis的#{}），对用户输入进行校验和过滤。
+3.  说一下 mybatis 的一级缓存和二级缓存
+    一级缓存是SqlSession级别的，默认开启；二级缓存是Mapper级别的，需要配置开启，多个SqlSession共享。
+4.  mybatis 是否支持延迟加载？延迟加载的原理是什么？
+    支持。原理是在需要时通过AOP动态生成实现类，调用时再去加载关联数据。
+5.  mybatis 动态sql中使用<where>标签与直接写where关键字有什么区别？
+    <where>标签会自动判断条件是否存在，自动添加WHERE关键字，并处理多余AND/OR；直接写WHERE需要手动处理。
+6.  mybatis 动态sql标签中循环标签中有哪些属性，各自的作用。
+    <foreach>标签有collection（集合）、item（元素别名）、index（索引别名）、open（开始符号）、separator（分隔符）、close（结束符号）等属性。
+7.  mybatis 和 hibernate 的区别有哪些？
+    MyBatis是半自动ORM，需要手动编写SQL；Hibernate是全自动ORM，自动生成SQL。MyBatis更灵活，Hibernate更方便。
+8.  RowBounds是一次性查询全部结果吗？为什么？
+    是的。RowBounds通过内存分页实现，底层还是一次性查了所有数据，在Java层面进行截取。
+9.  MyBatis 定义的接口，怎么找到实现的？
+    通过接口的全限定名在Mapper.xml中查找对应的SQL语句作为实现。
 10. Mybatis的底层实现原理。
+    通过反射、动态代理、OGNL表达式等技术，将Java对象与SQL语句进行映射，执行数据库操作。
 11. Mybatis是如何进行分页的？分页插件的原理是什么？
+    可以通过RowBounds或SQL语句（如limit）分页。分页插件通过拦截器拦截SQL，在SQL后添加limit语句实现。
 12. Mybatis执行批量插入，能返回数据库主键列表吗？
+    可以，通过配置useGeneratedKeys="true"和keyProperty指定主键字段。
 13. Mybatis都有哪些Executor执行器？它们之间的区别是什么？
+    SimpleExecutor（简单执行器）、ReuseExecutor（可重用Statement执行器）、BatchExecutor（批处理执行器）、ReuseExecutor（可重用Statement执行器）、CachingExecutor（缓存执行器）。区别在于Statement的重用、批处理和缓存策略不同。
 14. Mybatis动态sql有什么用？执行原理？有哪些动态sql？
+    动态SQL用于根据不同条件拼接SQL语句。原理是MyBatis在运行时根据传入参数，通过OGNL表达式解析XML中的标签，动态生成SQL。标签有<if>、<choose>、<when>、<otherwise>、<foreach>、<trim>、<where>、<set>等。
 15. mybatis有几种分页方式？
+    常见的有RowBounds分页、物理分页（SQL语句limit）、分页插件分页。
 16. MyBatis框架的优点和缺点
+    优点：SQL灵活，学习曲线平缓，性能较好。缺点：需要编写SQL，对复杂查询维护性稍差。
 17. 使用MyBatis框架，当实体类中的属性名和表中的字段名不一样 ，怎么办 ？
+    可以通过resultMap标签进行字段与属性的映射，或者在SQL中使用别名。
 18. 通常一个Xml映射文件，都会写一个Dao接口与之对应，请问，这个Dao接口的工作原理是什么？Dao接口里的方法，参数不同时，方法能重载吗？
+    工作原理是通过接口的全限定名找到对应的Mapper.xml文件执行SQL。接口方法不能重载，MyBatis通过方法名和参数类型区分方法。
 19. Xml映射文件中，除了常见的select|insert|updae|delete标签之外，还有哪些标签？
-20. 简述Mybatis的插件运行原理，以及如何编写一个插件。
\ No newline at end of file
+    还有<resultMap>、<sql>、<insert>、<update>、<delete>、<select>、<if>、<choose>、<when>、<otherwise>、<foreach>、<trim>、<where>、<set>等。
+20. 简述Mybatis的插件运行原理，以及如何编写一个插件。
+    原理：MyBatis通过动态代理生成Mapper接口的代理对象，插件通过实现Interceptor接口，在intercept方法中拦截Executor、StatementHandler、ParameterHandler、ResultSetHandler等对象的特定方法，进行增强处理。编写插件需要实现Interceptor接口，重写intercept、plugin、setProperties方法，并在配置文件中注册。
\ No newline at end of file

From 1364ce0f4d85b5018cef93d886abf5e946dfe53d Mon Sep 17 00:00:00 2001
From: plumbin <libinjavaw@gmail.com>
Date: Wed, 25 Jun 2025 16:07:09 +0800
Subject: [PATCH 9/9] =?UTF-8?q?=E7=BC=96=E7=A0=81?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 ...42\346\223\215\344\275\234\357\274\237.md" | 260 +++++++++---------
 1 file changed, 130 insertions(+), 130 deletions(-)

diff --git "a/\345\244\247\345\216\202\351\235\242\350\257\225\347\234\237\351\242\230/\351\230\277\351\207\214\344\270\200\351\235\242\357\274\214\347\273\231\344\272\206\345\207\240\346\235\241SQL\357\274\214\351\227\256\351\234\200\350\246\201\346\211\247\350\241\214\345\207\240\346\254\241\346\240\221\346\220\234\347\264\242\346\223\215\344\275\234\357\274\237.md" "b/\345\244\247\345\216\202\351\235\242\350\257\225\347\234\237\351\242\230/\351\230\277\351\207\214\344\270\200\351\235\242\357\274\214\347\273\231\344\272\206\345\207\240\346\235\241SQL\357\274\214\351\227\256\351\234\200\350\246\201\346\211\247\350\241\214\345\207\240\346\254\241\346\240\221\346\220\234\347\264\242\346\223\215\344\275\234\357\274\237.md"
index a695048..c7732f8 100644
--- "a/\345\244\247\345\216\202\351\235\242\350\257\225\347\234\237\351\242\230/\351\230\277\351\207\214\344\270\200\351\235\242\357\274\214\347\273\231\344\272\206\345\207\240\346\235\241SQL\357\274\214\351\227\256\351\234\200\350\246\201\346\211\247\350\241\214\345\207\240\346\254\241\346\240\221\346\220\234\347\264\242\346\223\215\344\275\234\357\274\237.md"
+++ "b/\345\244\247\345\216\202\351\235\242\350\257\225\347\234\237\351\242\230/\351\230\277\351\207\214\344\270\200\351\235\242\357\274\214\347\273\231\344\272\206\345\207\240\346\235\241SQL\357\274\214\351\227\256\351\234\200\350\246\201\346\211\247\350\241\214\345\207\240\346\254\241\346\240\221\346\220\234\347\264\242\346\223\215\344\275\234\357\274\237.md"
@@ -1,104 +1,104 @@
-###  ǰ��
+###  前言
 
-��λ����ȥ�������ԣ���˵���Թٸ��˼�����ѯSQL����:��Ҫִ�м��������������������ѵ�ʱ���е��µģ������侲˼�����ŷ��־��ǿ������ļ�������֪ʶ��~~ �������Ƿ־Ÿ�����֪ʶ�㣬һ����̽��һ�¡�����в���ȷ�Ļ�����ӭָ������һ��ѧϰ~
+有位朋友去阿里面试，他说面试官给了几条查询SQL，问:需要执行几次树搜索操作？我朋友当时是有点懵的，后来冷静思考，才发现就是考索引的几个基础知识点~~ 本文我们分九个索引知识点，一起来探讨一下。如果有不正确的话，欢迎指出哈，一起学习~
 
-- ���ںţ�**�����ݵ�С�к�**
-- github��ַ����лÿ��star
+- 公众号：**捡田螺的小男孩**
+- github地址，感谢每颗star
 > https://github.com/whx123/JavaHome
 
-- ���Թٿ���֮������ʲô��
-- ���Թٿ���֮��������
-- ���Թٿ���֮Ϊʲôѡ��B+����Ϊ�����ṹ
-- ���Թٿ���֮һ��������������
-- ���Թٿ���֮��������
-- ���Թٿ���֮����ʧЧ����
-- ���Թٿ���֮����ǰ׺
-- ���Թٿ���֮��������
-- ���Թٿ���֮�����������
+- 面试官考点之索引是什么？
+- 面试官考点之索引类型
+- 面试官考点之为什么选择B+树作为索引结构
+- 面试官考点之一次索引搜索过程
+- 面试官考点之覆盖索引
+- 面试官考点之索引失效场景
+- 面试官考点之最左前缀
+- 面试官考点之索引下推
+- 面试官考点之大表添加索引
 
-### һ�����Թٿ���֮������ʲô��
+### 一、面试官考点之索引是什么？
 
 ![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/21eed26e34534b51aadf28d5defaed7e~tplv-k3u1fbpfcp-watermark.image)
 
-- ������һ����������ݿ��ѯЧ�ʵ����ݽṹ�������Ա���һ���ֵ��Ŀ¼�����԰�������ҵ���Ӧ�ļ�¼��
-- ����һ��洢�ڴ��̵��ļ��У�����ռ�������ռ�ġ�
-- ����νˮ�����ۣ�Ҳ�ܸ��ۡ��ʵ�����������߲�ѯЧ�ʣ������������Ӱ�����ݿ���IJ���͸��¹��ܡ�
+- 索引是一种能提高数据库查询效率的数据结构。它可以比作一本字典的目录，可以帮你快速找到对应的记录。
+- 索引一般存储在磁盘的文件中，它是占用物理空间的。
+- 正所谓水能载舟，也能覆舟。适当的索引能提高查询效率，过多的索引会影响数据库表的插入和更新功能。
 
-### ��������������������
+### 二、索引有哪些类型类型
 
 ![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/cf6725e1a8cb44b496cca8fa45e15c2f~tplv-k3u1fbpfcp-watermark.image)
 
-#### ���ݽṹά��
+#### 数据结构维度
 
-- B+���������������ݴ洢��Ҷ�ӽڵ㣬���Ӷ�ΪO(logn)���ʺϷ�Χ��ѯ��
-- ��ϣ����:  �ʺϵ�ֵ��ѯ������Ч�ʸߣ�һ�ε�λ��
-- ȫ��������MyISAM��InnoDB�ж�֧��ʹ��ȫ��������һ�����ı�����char,text,varchar�����ϴ�����
-- R-Tree����: ������GIS�������ʹ���SPATIAL����
+- B+树索引：所有数据存储在叶子节点，复杂度为O(logn)，适合范围查询。
+- 哈希索引:  适合等值查询，检索效率高，一次到位。
+- 全文索引：MyISAM和InnoDB中都支持使用全文索引，一般在文本类型char,text,varchar类型上创建。
+- R-Tree索引: 用来对GIS数据类型创建SPATIAL索引
 
-#### �����洢ά��
+#### 物理存储维度
 
-- �ۼ��������ۼ�����������������������������Ҷ�ӽڵ�洢���DZ��е����ݡ�
-- �Ǿۼ��������Ǿۼ����������Է�������������������Ҷ�ӽڵ�洢���������������С�
+- 聚集索引：聚集索引就是以主键创建的索引，在叶子节点存储的是表中的数据。
+- 非聚集索引：非聚集索引就是以非主键创建的索引，在叶子节点存储的是主键和索引列。
 
-#### �߼�ά��
+#### 逻辑维度
 
-- ����������һ�������Ψһ�������������п�ֵ��
-- ��ͨ������MySQL�л����������ͣ�������ֵ���ظ�ֵ��
-- ��������������ֶδ�����������ʹ��ʱ��ѭ����ǰ׺ԭ��
-- Ψһ�������������е�ֵ������Ψһ�ģ���������Ϊ��ֵ��
-- �ռ�������MySQL5.7֮��֧�ֿռ��������ڿռ������ⷽ����ѭOpenGIS��������ģ�͹���
+- 主键索引：一种特殊的唯一索引，不允许有空值。
+- 普通索引：MySQL中基本索引类型，允许空值和重复值。
+- 联合索引：多个字段创建的索引，使用时遵循最左前缀原则。
+- 唯一索引：索引列中的值必须是唯一的，但是允许为空值。
+- 空间索引：MySQL5.7之后支持空间索引，在空间索引这方面遵循OpenGIS几何数据模型规则。
 
-### �������Թٿ���֮Ϊʲôѡ��B+����Ϊ�����ṹ
+### 三、面试官考点之为什么选择B+树作为索引结构
 
-���ԴӼ���ά��ȥ��������⣬��ѯ�Ƿ񹻿죬Ч���Ƿ��ȶ����洢���ݶ��٣��Լ����Ҵ��̴����ȵȡ�Ϊʲô���ǹ�ϣ�ṹ��Ϊʲô���Ƕ�������Ϊʲô����ƽ���������Ϊʲô����B������ƫƫ��B+���أ�
+可以从几个维度去看这个问题，查询是否够快，效率是否稳定，存储数据多少，以及查找磁盘次数等等。为什么不是哈希结构？为什么不是二叉树，为什么不是平衡二叉树，为什么不是B树，而偏偏是B+树呢？
 
-����дҵ��SQL��ѯʱ�����������£����Ƿ�Χ��ѯ�ģ���һ��SQL
+我们写业务SQL查询时，大多数情况下，都是范围查询的，如一下SQL
 ```
 select * from employee where age between 18 and 28;
 ```
-#### Ϊʲô��ʹ�ù�ϣ�ṹ��
-����֪����ϣ�ṹ������k-v�ṹ��Ҳ���ǣ�key��value��һ��һ��ϵ��������**��ֵ��ѯ**�����ԣ����Ƿ�Χ��ѯ��������Ϊ����Ŷ��
+#### 为什么不使用哈希结构？
+我们知道哈希结构，类似k-v结构，也就是，key和value是一对一关系。它用于**等值查询**还可以，但是范围查询它是无能为力的哦。
 
-#### Ϊʲô��ʹ�ö������أ�
+#### 为什么不使用二叉树呢？
 
-�Ȼ����¶��������֪ʶ��~ ��ν**���������ص����£�**
-- ÿ�������������������ֱ��Ϊ����������������
-- ���ӽڵ��ֵС�ڵ�ǰ�ڵ��ֵ����ǰ�ڵ�ֵС�����ӽڵ�ֵ
-- ���˵Ľڵ��Ϊ���ڵ㣬û���ӽڵ�Ľڵ�ֵ��ΪҶ�ӽڵ㡣
+先回忆下二叉树相关知识啦~ 所谓**二叉树，特点如下：**
+- 每个结点最多两个子树，分别称为左子树和右子树。
+- 左子节点的值小于当前节点的值，当前节点值小于右子节点值
+- 顶端的节点称为跟节点，没有子节点的节点值称为叶子节点。
 
-�����Ժ��У������׾͸��ֳ����ֶ������ṹͼ��
+我们脑海中，很容易就浮现出这种二叉树结构图：
 ![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8d4c349a7bda4b3db1791f9cff9c093e~tplv-k3u1fbpfcp-watermark.image)
 
-�����أ���Щ�����������������������Ŷ��
+但是呢，有些特殊二叉树，它可能这样的哦：
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/97b71a48d43545a0bc20a55adf2be207~tplv-k3u1fbpfcp-watermark.image)
 
-������������⻯Ϊһ���������൱��ȫ��ɨ�衣��ô��Ҫ��������ѽ����ˣ�һ����������ʺ���Ϊ�����ṹ��
+如果二叉树特殊化为一个链表，相当于全表扫描。那么还要索引干嘛呀？因此，一般二叉树不适合作为索引结构。
 
-#### Ϊʲô��ʹ��ƽ��������أ�
+#### 为什么不使用平衡二叉树呢？
 
-ƽ��������ص㣺��Ҳ��һ�Ŷ�����������κνڵ�����������߶�����Ϊ1�����ԾͲ���������⻯һ���������������
+平衡二叉树特点：它也是一颗二叉查找树，任何节点的两个子树高度最大差为1。所以就不会出现特殊化一个链表的情况啦。
 
 ![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/74afa9b54e7f4c0996ff83e66016c09a~tplv-k3u1fbpfcp-watermark.image)
 
-�����أ�
-- ƽ�������������߸����ǣ���Ҫ��������ά��ƽ�⣬ά�����۴�
-- ���������Ļ������ĸ߶Ȼ�ܸߡ���Ϊ�����Ǵ��ڴ��̵ģ�������Ϊ�����ṹ��ÿ�δӴ��̶�ȡһ���ڵ㣬����IO�Ĵ����Ͷ�����
+但是呢：
+- 平衡二叉树插入或者更新是，需要左旋右旋维持平衡，维护代价大
+- 如果数量多的话，树的高度会很高。因为数据是存在磁盘的，以它作为索引结构，每次从磁盘读取一个节点，操作IO的次数就多啦。
 
 
-#### Ϊʲô��ʹ��B���أ�
+#### 为什么不使用B树呢？
 
 
-��������Ļ���ƽ��������ĸ߶Ȼ�ܸߣ�������IO���Ϊʲô��ѡ��ͬ����������**�߶ȸ�����B��**�أ�
+数据量大的话，平衡二叉树的高度会很高，会增加IO嘛。那为什么不选择同样数据量，**高度更矮的B树**呢？
 
 ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/acc8f2e2cfb54092b4fb131e500334a3~tplv-k3u1fbpfcp-watermark.image)
 
-B�������ƽ����������Ϳ��Դ洢��������ݣ��߶ȸ��͡��������Ϊ��ѡ��B+���أ���ΪB+����B���������棺
-- B+����Ҷ�ӽڵ����Dz��洢���ݵģ����洢��ֵ����B���ڵ��в����洢��ֵ��Ҳ��洢���ݡ�innodb��ҳ��Ĭ�ϴ�С��16KB��������洢���ݣ���ô�ͻ�洢����ļ�ֵ����Ӧ�����Ľ������ڵ���ӽڵ������ͻ�������ͻ�������֣����һ�����Dz������ݽ��д��̵�IO�����л��ٴμ��٣����ݲ�ѯ��Ч��Ҳ����졣
-- B+���������������ݾ��洢��Ҷ�ӽڵ㣬���������ǰ���˳�����еģ��������ŵġ���ôB+��ʹ�÷�Χ���ң�������ң���������Լ�ȥ�ز��ұ���쳣�򵥡�
+B树相对于平衡二叉树，就可以存储更多的数据，高度更低。但是最后为甚选择B+树呢？因为B+树是B树的升级版：
+- B+树非叶子节点上是不存储数据的，仅存储键值，而B树节点中不仅存储键值，也会存储数据。innodb中页的默认大小是16KB，如果不存储数据，那么就会存储更多的键值，相应的树的阶数（节点的子节点树）就会更大，树就会更矮更胖，如此一来我们查找数据进行磁盘的IO次数有会再次减少，数据查询的效率也会更快。
+- B+树索引的所有数据均存储在叶子节点，而且数据是按照顺序排列的，链表连着的。那么B+树使得范围查找，排序查找，分组查找以及去重查找变得异常简单。
 
-### �ġ����Թٿ���֮һ��B+��������������
+### 四、面试官考点之一次B+树索引搜索过程
 
-**���Թ٣�** ���������±��ṹ���������⼸������
+**面试官：** 假设有以下表结构，并且有这几条数据
 ```
 CREATE TABLE `employee` (
   `id` int(11) NOT NULL,
@@ -110,137 +110,137 @@ CREATE TABLE `employee` (
   KEY `idx_age` (`age`) USING BTREE
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
-insert into employee values(100,'��',43,'2021-01-20','0');
-insert into employee values(200,'����',48,'2021-01-21','0');
-insert into employee values(300,'����',36,'2020-01-21','1');
-insert into employee values(400,'����',32,'2020-01-21','0');
-insert into employee values(500,'��Ѹ',37,'2020-01-21','1');
-insert into employee values(600,'��',49,'2021-01-21','0');
-insert into employee values(700,'��',28,'2021-01-21','1');
+insert into employee values(100,'小伦',43,'2021-01-20','0');
+insert into employee values(200,'俊杰',48,'2021-01-21','0');
+insert into employee values(300,'紫琪',36,'2020-01-21','1');
+insert into employee values(400,'立红',32,'2020-01-21','0');
+insert into employee values(500,'易迅',37,'2020-01-21','1');
+insert into employee values(600,'小军',49,'2021-01-21','0');
+insert into employee values(700,'小燕',28,'2021-01-21','1');
 ```
 
-**���Թ٣�** ���ִ�����µIJ�ѯSQL����Ҫִ�м��ε����������������Ի��¶�Ӧ�������ṹͼ~
+**面试官：** 如果执行以下的查询SQL，需要执行几次的树搜索操作？可以画下对应的索引结构图~
 ```
 select * from Temployee where age=32;
 ```
 
-**������** ��ʵ��������Թپ��ǿ����ѡ���Ƿ���ϤB+�������ṹͼ���������ϻش�~
+**解析：** 其实这个，面试官就是考察候选人是否熟悉B+树索引结构图。可以像酱紫回答~
 
-- �Ȼ���`idx_age`�����������ṹͼ��������£�
+- 先画出`idx_age`索引的索引结构图，大概如下：
 
 ![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/f88457b43e354ca18795fa0033ad075f~tplv-k3u1fbpfcp-watermark.image)
 
-- �ٻ���id���������������Ȼ������������ṹͼ�����£�
+- 再画出id主键索引，我们先画出聚族索引结构图，如下：
 
 ![](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/963a8dacb39345008c93b1d0ea079eec~tplv-k3u1fbpfcp-watermark.image)
 
 
-��ˣ����� SQL ��ѯ���ִ�д�����̾��ǽ��ϣ�
-- 1. ����`idx_age`�������������̿�1���ص��ڴ棬����32<37,������·��֧��������Ѱַ���̿�2��
-- 2. �����̿�2���ص��ڴ��У����ڴ�����������ҵ�age=32�ļ�¼��ȡ��id = 400.
-- 3. �õ�id=400�󣬻ص�id������������
-- 4. ����`id����`�������������̿�1�����ڴ棬���ڴ�������ҵ���400������B+��������Ҷ�ӽڵ��Dz��������ݵġ��������������400���ҷ�֧��������Ѱַ���̿�3.
-- 5. �����̿�3�����ڴ棬���ڴ�������ҵ�id=400�ļ�¼���õ�R4��һ�е����ݣ��õģ��󹦸�ɡ�
+因此，这条 SQL 查询语句执行大概流程就是酱紫：
+- 1. 搜索`idx_age`索引树，将磁盘块1加载到内存，由于32<37,搜索左路分支，到磁盘寻址磁盘块2。
+- 2. 将磁盘块2加载到内存中，在内存继续遍历，找到age=32的记录，取得id = 400.
+- 3. 拿到id=400后，回到id主键索引树。
+- 4. 搜索`id主键`索引树，将磁盘块1加载内存，在内存遍历，找到了400，但是B+树索引非叶子节点是不保存数据的。索引会继续搜索400的右分支，到磁盘寻址磁盘块3.
+- 5. 将磁盘块3加载内存，在内存遍历，找到id=400的记录，拿到R4这一行的数据，好的，大功告成。
 
-��ˣ����SQL��ѯ��ִ���˼������������������Dz���һ����Ȼ��ѽ��**�ر��**����`idx_age`�����������ҵ�����`id`�󣬻ص�id�������������Ĺ���,�ͳ�Ϊ�ر���
-> ʲô�ǻر����õ������ٻص�����������ѯ�Ĺ��̣��ͽ���**�ر�**
+因此，这个SQL查询，执行了几次树的搜索操作，是不是一步了然了呀。**特别的**，在`idx_age`二级索引树找到主键`id`后，回到id主键索引搜索的过程,就称为回表。
+> 什么是回表？拿到主键再回到主键索引查询的过程，就叫做**回表**
 
-### �塢���Թٿ���֮��������
+### 五、面试官考点之覆盖索引
 
-**���Թ٣�** �������`select *`, ����ʹ��`select id,age`�����ϵ���Ŀִ���˼��������������أ�
+**面试官：** 如果不用`select *`, 而是使用`select id,age`，以上的题目执行了几次树搜索操作呢？
 
-**������** ������⣬��Ҫ�����ѡ�˵ĸ�������֪ʶ�㡣�ص�`idx_age`������������Է��ֲ�ѯѡ��id��age����Ҷ�ӽڵ����ˡ���ˣ�����ֱ���ṩ��ѯ������������Ͳ���Ҫ�ٻر���~
+**解析：** 这个问题，主要考察候选人的覆盖索引知识点。回到`idx_age`索引树，你可以发现查询选项id和age都在叶子节点上了。因此，可以直接提供查询结果啦，根本就不需要再回表了~
 
 ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/629b6cfd08614adcbb20154707c0c8e0~tplv-k3u1fbpfcp-watermark.image)
 
-> �����������ڲ�ѯ�����������棬����Ҫ�ر�ȥ�飬ֱ�Ӵ������о���ȡ����Ҫ�Ľ�������仰˵����SQL�õ������������ݣ������˲�ѯ������У������ϸ��������ˡ�
+> 覆盖索引：在查询的数据列里面，不需要回表去查，直接从索引列就能取到想要的结果。换句话说，你SQL用到的索引列数据，覆盖了查询结果的列，就算上覆盖索引了。
 
-���ԣ�������ϸ����⣬����ʡȥ�˻ر���������������
+所以，相对于上个问题，就是省去了回表的树搜索操作。
 
-### �������Թٿ���֮����ʧЧ
+### 六、面试官考点之索引失效
 
-**���Թ٣�** ��������ڸ�`name`�ֶμ�����ͨ������Ȼ���ø�likeģ���������ǻ�ִ�ж��ٴβ�ѯ�أ�SQL���£�
+**面试官：** 如果我现在给`name`字段加上普通索引，然后用个like模糊搜索，那会执行多少次查询呢？SQL如下：
 ```
-select * from employee where name like '%����%';
+select * from employee where name like '%杰伦%';
 ```
-**������** ������֪ʶ����ǣ�like�Ƿ�ᵼ�²������������ȸ�SQL��explainִ�мƻ��ɡ���ʵlike ģ���������ᵼ�²��������ģ����£�
+**解析：** 这里考察的知识点就是，like是否会导致不走索引，看先该SQL的explain执行计划吧。其实like 模糊搜索，会导致不走索引的，如下：
 
 ![](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3b01bb44ff5744729e55939cc88bd424~tplv-k3u1fbpfcp-watermark.image)
 
-��ˣ�����SQL����ȫ��ɨ����~�ճ������У��⼸��ɧ���������ܻᵼ������ʧЧ�����£�
-- ��ѯ��������or�����ܵ�������ʧЧ
-- ����ֶ��������ַ�����whereʱһ������������������������ʧЧ
-- likeͨ������ܵ�������ʧЧ��
-- ������������ѯʱ�������в������������еĵ�һ���У�����ʧЧ��
-- ����������ʹ��mysql�����ú���������ʧЧ��
-- �����������㣨�磬+��-��*��/��������ʧЧ��
-- �����ֶ���ʹ�ã���= ���� < >��not in��ʱ�����ܻᵼ������ʧЧ��
-- �����ֶ���ʹ��is null�� is not null�����ܵ�������ʧЧ��
-- �����Ӳ�ѯ���������Ӳ�ѯ��ѯ�������ֶα����ʽ��һ�������ܵ�������ʧЧ��
-- mysql����ʹ��ȫ��ɨ��Ҫ��ʹ��������,��ʹ��������
-
-### �ߡ����Թٿ�����������֮����ǰ׺ԭ��
-
-**���Թ٣�**  ��������ڸ�name,age�ֶμ���������������������SQLִ�ж��ٴ��������أ��Ȼ�����������
+因此，这条SQL最后就全表扫描啦~日常开发中，这几种骚操作都可能会导致索引失效，如下：
+- 查询条件包含or，可能导致索引失效
+- 如何字段类型是字符串，where时一定用引号括起来，否则索引失效
+- like通配符可能导致索引失效。
+- 联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
+- 在索引列上使用mysql的内置函数，索引失效。
+- 对索引列运算（如，+、-、*、/），索引失效。
+- 索引字段上使用（！= 或者 < >，not in）时，可能会导致索引失效。
+- 索引字段上使用is null， is not null，可能导致索引失效。
+- 左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
+- mysql估计使用全表扫描要比使用索引快,则不使用索引。
+
+### 七、面试官考点联合索引之最左前缀原则
+
+**面试官：**  如果我现在给name,age字段加上联合索引索引，以下SQL执行多少次树搜索呢？先画下索引树？
 ```
-select * from employee where name like 'С%' order by age desc;
+select * from employee where name like '小%' order by age desc;
 ```
-**������** �������������������ǰ׺ԭ���Լ�like�Ƿ���������֪ʶ�㡣���������ʾ��ͼ������£�
+**解析：** 这里考察联合索引的最左前缀原则以及like是否中索引的知识点。组合索引树示意图大概如下：
 
 ![](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/29df075df94549b693a6a0ee06730666~tplv-k3u1fbpfcp-watermark.image)
 
-�������������Ȱ�����name��С���������������name��ͬ��������age��С�����������Թ�Ҫ����������ֵ�һ�����ǡ�С�����ˣ�SQL��like 'С%'�ǿ�������```idx_name_age```���������ġ�
+联合索引项是先按姓名name从小到大排序，如果名字name相同，则按年龄age从小到大排序。面试官要求查所有名字第一个字是“小”的人，SQL的like '小%'是可以用上```idx_name_age```联合索引的。
 
 ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/58b49f88f75f48be873deb395431c2fa~tplv-k3u1fbpfcp-watermark.image)
 
-�ò�ѯ������idx_name_age���������ҵ���һ������С������ֵ����������ҵ�```С����С�ס�С�ࡢ```���ֱ��õ�Id=```600��100��700```��Ȼ������α���ȥ�Ҷ�Ӧ�ļ�¼�� �����������ǰ׺```С```�������ַ�������������M���ַ���ʵ���ϣ�
-- �������ǰ׺��������������������N���ֶΡ��������������a,b,c�������൱�ڽ��ˣ�a������a,b��,(a,b,c)��������������������������������
-- ����ǰ׺Ҳ�������ַ�������������M���ַ���
+该查询会沿着idx_name_age索引树，找到第一个字是小的索引值，因此依次找到```小军、小伦、小燕、```，分别拿到Id=```600、100、700```，然后回三次表，去找对应的记录。 这里面的最左前缀```小```，就是字符串索引的最左M个字符。实际上，
+- 这个最左前缀可以是联合索引的最左N个字段。比如组合索引（a,b,c）可以相当于建了（a），（a,b）,(a,b,c)三个索引，大大提高了索引复用能力。
+- 最左前缀也可以是字符串索引的最左M个字符。
 
-### �ˡ����Թٿ���֮��������
+### 八、面试官考点之索引下推
 
-**���Թ٣�** ���ǻ��Ǿ���������� idx_name_age���������SQLִ�м����������أ�
+**面试官：** 我们还是居于组合索引 idx_name_age，以下这个SQL执行几次树搜索呢？
 
 ```
-select * from employee where name like 'С%' and age=28 and sex='0';
+select * from employee where name like '小%' and age=28 and sex='0';
 ```
 
-**������** ������������Ƶ�֪ʶ�㣬�����**Mysql5.6֮ǰ**����idx_name_age���������ҳ��������ֵ�һ�����ǡ�С�����ˣ��õ����ǵ�����id��Ȼ��ر��ҳ������У���ȥ�Ա�������Ա�������ֶΡ���ͼ��
+**解析：** 这里考察索引下推的知识点，如果是**Mysql5.6之前**，在idx_name_age索引树，找出所有名字第一个字是“小”的人，拿到它们的主键id，然后回表找出数据行，再去对比年龄和性别等其他字段。如图：
 
 ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c5729b1a84fd4ee9b872717903ca6f75~tplv-k3u1fbpfcp-watermark.image)
 
-��Щ���ѿ��ܾ�����֣���name,age)�������������Ϊʲôѡ��������С���ֺ󣬲���˳�㿴������age�ٻر��أ����Ǹ���Ч�����ѽ��MySQL 5.6 ��������**���������Ż�**���������������������У��������а������ֶ������жϣ�ֱ�ӹ��˵������������ļ�¼�����ٻر�������
+有些朋友可能觉得奇怪，（name,age)不是联合索引嘛？为什么选出包含“小”字后，不再顺便看下年龄age再回表呢，不是更高效嘛？所以呀，MySQL 5.6 就引入了**索引下推优化**，可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
 
 
-��ˣ�MySQL5.6�汾֮��ѡ��������С���ֺ�˳������age=28��,���Ծ�ֻ��һ�λر���
+因此，MySQL5.6版本之后，选出包含“小”字后，顺表过滤age=28，,所以就只需一次回表。
 
 ![](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/168aecb4709d4c30bc93c489ad76d712~tplv-k3u1fbpfcp-watermark.image)
 
-### �š� ���Թٿ���֮�����������
+### 九、 面试官考点之大表添加索引
 
-**���Թ٣�** ���һ�ű�����������ǧ�򼶱����ϵģ���ô�������ű���������������Ҫ��ô���أ�
+**面试官：** 如果一张表数据量级是千万级别以上的，那么，给这张表添加索引，你需要怎么做呢？
 
-**������** ������Ҫ֪��һ�㣬��������������ʱ���ǻ�Ա������ġ�����������������п��ܳ��������¹ʵġ����Բο����·�����
+**解析：** 我们需要知道一点，给表添加索引的时候，是会对表加锁的。如果不谨慎操作，有可能出现生产事故的。可以参考以下方法：
 
-- 1.�ȴ���һ�Ÿ�ԭ��A���ݽṹ��ͬ���±�B��
-- 2.���±�B������Ҫ���ϵ���������
-- 3.��ԭ��A���ݵ����±�B
-- 4.rename�±�BΪԭ���ı���A��ԭ��A����ı�����
+- 1.先创建一张跟原表A数据结构相同的新表B。
+- 2.在新表B添加需要加上的新索引。
+- 3.把原表A数据导到新表B
+- 4.rename新表B为原表的表名A，原表A换别的表名；
 
-### �ܽ�����ϰ
+### 总结与练习
 
-������Ҫ������������9��ؼ�֪ʶ�㣬ϣ���Դ���а������������أ�����ҳ�һ�����й��������ҵ�񿪷������ļ�����SQL�����´������ô�ش�ģ�����Ȥ������ϵ�ҹ�~��Ŀ���£�
+本文主要讲解了索引的9大关键知识点，希望对大家有帮助。接下来呢，给大家出一道，有关于我最近业务开发遇到的加索引SQL，看下大家是怎么回答的，有兴趣可以联系我哈~题目如下：
 ```
 
 select * from A where type ='1' and status ='s' order by create_time desc;
 ```
-����type��9�����ͣ����ֶ��Ի�����ԣ�status�����ֶȲ��ߣ���3�����ͣ�����ô������μ������أ�
-- �Ǹ�type�ӵ�����
-- ���ǣ�type��status��create_time����������
-- ���ǣ�type��create_time�����������أ�
-
-### �ο����л
-- [ MySQL������������ ?](https://segmentfault.com/q/1010000003832312)
-- [�������������](https://zhuanlan.zhihu.com/p/151460679)
--  [MySQLʵս45��](https://time.geekbang.org/column/article/69636)
+假设type有9种类型，区分度性还算可以，status的区分度不高（有3种类型），那么你是如何加索引呢？
+- 是给type加单索引
+- 还是（type，status，create_time）联合索引
+- 还是（type，create_time）联合索引呢？
+
+### 参看与感谢
+- [ MySQL有哪些索引类型 ?](https://segmentfault.com/q/1010000003832312)
+- [大表加索引方案](https://zhuanlan.zhihu.com/p/151460679)
+-  [MySQL实战45讲](https://time.geekbang.org/column/article/69636)