大家好，我是IT枫斗者团队的程序员枫哥，🌟阿里云技术专家、📝资深面试官、🌹Java跳槽网课堂创始人。拥有多年一线研发经验，曾就职过科大讯飞、美团网、平安等公司。

• 需要看面试实战视频可以关注b站号：IT枫斗者–Java面试。
• 需要看技术文章，可以关注CSDN(全栈领域优秀创作者、技术专家博主、百万+访问量)：IT枫斗者。
• 需要找枫哥联系或者语音/电话沟通的看底部联系方式！

目前组建的技术团队，专注Java技术分享，一对一学习辅助，春招/秋招/社招/跳槽等求职辅助。

从2017年底开始做面试辅导，辅导成功上岸学员3000+，底部有我们的八年辅导历程，八年风雨不忘初心！

这是一个面向就业指导的训练营，真正做到保姆式一对一面试辅导，快速拿到offer。

# 我们能给你带来什么？

我们这里可以提供20多个大型的企业级互联网项目经验可选(都是技术老师真实接触的：非电商类、非物流外卖等。)，不同的情况我们匹配不同的项目经验，不同的工作年限我们负责模块和深度也不一样。

1. 企业级项目经验答疑，一直到你能够专业并且熟练的说出来为止！
2. 会把项目真实开发的迭代过程、业务逻辑和技术实现细节都详细讲解清楚，且整理出来项目文档和技术亮难点!
3. 一对一解答服务过程中遇到的疑难问题，实战面试总结，你记住面试过程中你不是一个人在战斗，我们都在！
4. 简历个性化代写，根据你的需求代写简历，动态调整简历，一直到有效果为止！
5. 还原真实面试现场，直到你能达到实战面试要求为止，不停的总结问题，解决问题！
6. 项目经验准备周期一个星期左右，主要是希望你能够快速入职！
7. 一次性收费无需其他费用，不要拿其他同行或者别人的价格便宜来跟我们对比，我只能说在同行中我们肯定降维打击，我们从2017年就开始了(结尾可以看我们八年来的辅助记录)，辅导经验和大型互联网项目经验不是别人能比的！试问七年前"同行他们"大学毕业了吗？随着训练营沉淀的内容越来越多，我们付出的精力更多的时候，后面肯定会涨价的，所以早加入训练营，是有价格优势的。

• 我们的最终目的是负责你收到offer为止，由于是企业级真实项目经验，我们整理了很多亮点和难点，并且技术老师自己也签过保密协议的，所以没有源码，但是会有负责模块部分的伪代码和详细的技术文档和视频讲解，更有不限次数多1V1腾旭会议讲解，目的是让你能够理解，确保你在面试的时候能够熟练的说出来！
• 顾虑和担心：很多小伙伴担心报名后找不到工作怎么办，问我们能不能保证，我只能说保障是双向的，只要你给你的信息是真实的并且积极配合我们，我们肯定能给你一个结果！

# 辅导内容及服务流程

offer突击训练营是针对找工作的小伙伴，给你一个offer保障！

面试知识体系，我们会监督你每天学习；项目，我们会把项目中技术点、业务功能、真实的开发过程都详细教清楚，不用让你耗时间去写代码，有针对性的去应对面试。我们提供真实的项目经验保证面试能够拿的出手。

• 1v1辅导群，摸底能力测评，定制面试学习计划
• 知识体系包含Java基础、Jvm、Mysql、Spring全家桶、Redis、MQ、设计模式、算法、大厂项目
• 每日问题总结，1V1腾讯会议解答、1V1语音电话解答、1V1日报问题文档解析
• 个性化简历代写、匹配企业级真实项目，配套项目讲解答疑、两轮模拟面试(多次技术栈面、多次项目面)
• 讲解简历投递策略，HR沟通技巧、1V1面试复盘，offer决策指导

套餐内容和服务流程如下：

# 大厂成功案例：

以下为学员近期部分录用喜报（信息均已脱敏处理），已覆盖百度、美团、阿里、科大讯飞、vivo、滴滴等多家知名企业，也包含字节、腾讯、京东、华为、网易、拼多多、B站、小米、携程、途虎等方向机会。

看着学员们在求职过程中一步步成长：从最初的紧张不安，到能够清晰表达项目亮点、从容应对面试，我们由衷感到欣慰。

每一份 offer 都不是偶然，而是长期准备、持续复盘和一次次突破后的结果。你负责全力以赴，我们负责陪你走到拿结果。

# 近期成功案例：

# 经典成功案例：

# 一年Java开发，本科，拿到华为od录用18k

• 工作年限：1.5年
• 学历：本科
• 初始预期薪资：13k
• 到手薪资：18k
• 介绍：学员在系统准备后顺利通过面试，offer 审批落地快，最终薪资较预期明显提升并顺利入职，过程细节见下方截图与说明。

# 逆袭大厂手撕算法，拿下滴滴offer入职34k

• 工作年限：6年
• 学历：211本科
• 初始预期薪资：29-30k
• 到手薪资：34k
• 介绍：围绕高并发与项目难点做了针对性梳理，面试节奏稳定推进并快速拿到结果，最终薪资高于预期区间，关键沟通记录见下方截图。

# 一年工作经验，本科，没有项目可以面试，最终拿下5个offer，总结出5个面经

• 工作年限：一年
• 学历：本科
• 初始预期薪资：10K
• 到手薪资：9K、10K、11K、10.5K、12k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 学历差？成人大专逆袭税后14.5K的offer已经成功入职！

• 工作年限：1年
• 学历：成人大专
• 初始预期薪资：7-9K
• 到手薪资：14.5K
• 介绍：针对学历门槛与面试信心不足的问题，先补齐 Java 核心与项目表达，再进行高频题和模拟面试强化，最终从 7-9K 预期提升到税后 14.5K 并顺利入职，完整过程见下方记录。

很多小伙伴觉得学历不好，没有什么面试机会，很难找到工作，确实现在学历不高，没有以前那么好找了，以前随便包装一下也能混进外包，现在难多了！

难，并不代表一点机会都没有，针对学历不占优势的，也非常想进入这一行一定要做好充分准备，从技术栈和项目经验上下功夫，突出你个人的能力！

同时入行以后，再提升你的学历，有经验以后，学历也不再是你的绊脚石了。

# 硕士应届生秋招，拿到深信服19k*15薪，年终0-6个月，600餐补

• 工作年限：0-1年
• 学历：硕士
• 初始预期薪资：18K*15薪
• 到手薪资：19k*15薪+年终0-6个月+600/月餐补
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 工作好几年薪资涨幅非常低，想要跳槽又怕没准备好，没有好的项目经验？

• 工作年限：3年
• 学历：本科
• 初始预期薪资：15-18K
• 到手薪资：18K
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

​ 在一家外包或者普通公司干了好几年，薪资涨幅非常低，但是自己几年技术栈又没有大的提升，又好久没有面试过了，感觉项目拿不出手，面试题、八股文、面试技巧、项目经验都不知道怎么弄！！！

​ 下面几个小伙伴都已经成功跳出舒适圈，拿到想要的offer！

经朋友介绍加入辅导后，系统梳理技术栈与项目表达，面试节奏明显提升，最终拿到年薪30W。

# 零基础自学，第一个offer：坐标青岛，年包24-25万一年。第二个offer：坐标北京，15.5*13薪，公积金和其他福利另算。

• 工作年限：0年起步
• 学历：普本
• 初始预期薪资：8-10K
• 到手薪资：年包24-25万一年

情况介绍：24年研究生毕业，之前自己去秋招一直各种不顺利，然后找到我们，原计划冲击一下秋招末班车，如果没有找到那就春招继续，所幸功夫不负有心人，在技术老师和小伙伴积极付出下拿到了两个offer。

# 从只会基础到拿下大厂度小满15*15k的offer，学员觉得是劝退价。。

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：15k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

情况说明：大四在校生，学校还不错，就是基础比较薄弱，只会一些java基础，连框架都没有学完，我们给定制了秋招训练营计划，赶上秋招的末班车，面试的期间也是非常坎坷，被好几家公司拒了，也是她的坚持不懈，最终收到度小满的offer，薪资15k*15薪！

# 九年开发经验，从别人那里报名一万多三个月后，简历还是狗不理，在b站上找到我们花了在别人那里的五分之一价格，经过辅导，拿到外企16K*14薪，朝九晚六双休，不加班

• 工作年限：九年
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：16K*14薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 函授本科，培训，半年多Java开发工作经验，西安拿下白菜价10k 朝九晚六双休

• 工作年限：0.5年+
• 学历：函授本科
• 初始预期薪资：未披露
• 到手薪资：10k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 民办本科非计算机自学转行拿到15k*14的offer

• 工作年限：未披露
• 学历：民办本科
• 初始预期薪资：未披露
• 到手薪资：15k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

情况说明：2019年民办本科毕业，油气储运工程专业，之前一直做销售，去年2022年的时候自学java，然后找了一个多月没有找到，通过朋友介绍找到我，然后辅助他入行，由于自学的底子比较弱，找到的一个10.5k的offer，在里面积累一年经验了，今年2023年想跳槽又找到我们，然后辅助找到一个15k*14的offer！

# 坐标深圳：三个offer，普通二本生物自学

• 工作年限：未披露
• 学历：普通二本
• 初始预期薪资：未披露
• 到手薪资：未披露
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

情况说明：2020年二本生物专业毕业，自学的，自己写的简历投了三四百份简历就两个面试，答的都不是很好，项目经验是最大的痛点，没有真实项目经验，按照他的话简历越投越迷茫，然后找到我们重新定制计划和资料，重新定制简历以下图片是整个辅助过程。

# 培训出来经过包装拿下四个offer，最高18k*15薪

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：18k*15薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

**情况说明：**刚培训结束，培训机构就业指导老师竟然让自己出去找项目，完全没有经验，什么都不会。

经过相关培训学过java，但是没有好项目来包装自己去找工作，经过我们的辅导，成功上岸！！

# 刚自学完，对面试非常惶恐，担心找不到工作？

• 工作年限：0-1年
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：未披露
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

​ 以下小伙伴是自学完，出来找工作，发现每次面试总是面试题回答的不满意，不是面试官想要的答案，还有项目经验是自学的完全拿不出手！

# 深信服26k*15薪，会问哪些技术？三年经验会有几轮面试

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：26k*15薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

说明：这个是最近找到的，我还专门做了一个面试总结采访，有兴趣的小伙伴可以看看。

# 坐标北京，30k*12薪

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：30k*12薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

说明：实际经验四年多，包装了一下写了五年多一些，这里hr面问什么也总结了

# 两个offer，上海11k&&湖南数字马力12k

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：11k；12k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 三个offer，17k的银行外包，14.5k的阿里，中证18k，季度奖4-8k，每月休息九天

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：17k；14.5k；18k；8k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 就业陪跑八年历程(八年风雨，不忘初心)

坚持一件事本身就不容易，如果坚持做一件事八年了那就更难了，各位小伙伴扪心自问，6-7年前多少人还是小白或者才开始学习，同行当中很多人都是才上大学甚至还没上大学吧，抖音上目前已知的有一些出来做辅导的是我几年前辅导过的，能把一件事坚持做七年，这样的人难道不值得你信任和让他们给你辅导面试吗？后面只要不退休互联网行业不崩，我们一直都在。

2018年（八年风雨，不忘初心）

慢慢的，除了贴吧写帖子，也开始CSDN和其他技术平台写技术文章了，写技术文章不仅是对自己的一个沉淀，也能帮助到更多的人学习技术，在一次一次辅导中得到小伙伴的肯定：“老哥还稳的”、“很强”、“真的很开心”。枫哥找到了做这个事情的意义！

2019年辅导记录：

一晃做辅导两年了，IT枫斗者团队迎来了新的技术老师，也是我们罗老师，同年我们推出了面试辅导套餐、简历定制套餐，为了让学员交易更有保障，我们也专门开了淘宝店。那一年几乎每个月都有辅助进大厂的，枫哥还内推了一个来自己公司的。

2020年辅导记录：

这一年是特殊的一年，也是IT枫斗者团队的一个转折点，因为封控很多小伙伴在家都很无聊，但是IT行业影响最小的因为可以远程办公，也就是那一年在线教育火了，这一年枫哥新增了私教带徒套餐，上线了专门为学徒学习的在线教育网站，团队也迎来了青木老师、淡漠老师，我们的大家庭又壮大了。

2021年辅导记录：

正所谓人红是非多，更何况我们还不是很火，在这一年有一些同行冒充枫哥的小号去坑人，这个时候枫哥意识到了要保护自己的权益也要保护相信自己的学员了，于是注册了商标，同时所有技术老师头像都是“IT枫斗者”+后缀，这样辅助记录截图出来也不怕别人盗图了。

2022年辅导记录：

这一年IT枫斗者团队迎来了丙丙老师的加入，同时这一年想要进国企和事业单位的特别多，还有想要考证的，很多来咨询枫哥的，为了这个枫哥亲自把国企和事业单位的面试和笔试都经历过一遍。同时也去考了计算机的软考的高级证书，还专门写了文章分享如何考证并且通过证书去领取人才补贴10万元。

2023年辅导记录：

现在看来这年是一个互联网行业的转折点， 2023年真的感受到了互联网的寒冬，在这一年之前几乎很多简历投出去面试很多，甚至发现外包都开始挑剔了。大厂和自研要求更是严格。同年韩清宗老师也加入了团队。在这一年枫哥做出了一个让大家都很吃惊决定，直接辞职了，全职开始做面试辅导，枫哥说现在行情差有很多的人需要他，他要对得起信任他的粉丝们，这一年开始了直播，也就是直播才发现抖音我们做的太晚了，有一些同行都已经十几万粉丝了，你要知道枫哥做辅导的时候那些同行还在上大学，通过短视频一包装摇身一变就是某大厂出来的了，不过他们确实抓住了风口。

2024年辅导记录：

每天都有很多人找枫哥抱怨，网上充满了负能量和大环境不好的声音，枫哥决定要做一些力所能及的事情了，专门做一些心里辅导，鼓励学员调整好心态，行情不好使面向大家，不是针对某一个人，只要准备好还是能找到工作的。就跟高考试卷难一样，大家都难，所以要做好更充分的准备。这一年我们的IT枫斗者-彬哥，加入了我们的团队。

2025年辅导记录：

八年风雨，不忘初心，我们一直都在，我们的团队也一直在壮大。今年我们团队又迎来了新的技术老师，2025年我们团队是创建以来最强阵容，大厂经验几乎是标配，也是今年我们把枫哥工作九年以来的面试超神之路资料直接开源了。2025年才过去一半，我们辅导了最高薪资月薪38K，我们辅导了多个成人学历找到工作，甚至还有高中毕业的也找到了（这个是真的不容易，要付出常人三倍努力不止）。截图到2025年5月份数据，IT枫斗者团队2025年一共辅导了91个学员，其中86个收到了offer，就业率达到百分之九十六，96%，在当下这个环境下能达到这个就业率，技术老师是下了很大功夫的。

2026年辅导记录：

2026年，我们持续强化“一对一诊断 + 面试复盘 + 项目表达优化”的陪跑体系，帮助更多同学在复杂行情下拿到更稳的面试结果。

# 如何报名？

如果你想报名，或者还有什么需要咨询的，可以加枫哥微信：itfdz666，加的时候备注：报名。

这些年，我在一线研发和面试筛选岗位都做过不少实践，也曾就职于科大讯飞、美团网、平安等公司。刚入行时我也经历过一段很长的迷茫期，四处碰壁，所以我非常清楚“想入行、想转型、想涨薪”这条路到底有多难。

我的起点

2014 年，我离开宿舍，独自去上海找机会。
那是我职业生涯真正意义上的起点，也是我后来做辅导的初心来源。

2014 年离开宿舍独自去上海（这里放你的原图）

为什么开始做辅导

从 2017 年开始，我利用业余时间做面试辅导、学习辅导，也带过不少学徒。
一开始目标很简单：希望能帮到那些入行困难、方向迷茫但又愿意努力的人。

后来我发现，仅靠零散答疑很难长期沉淀经验，于是：

• 2018 年：注册 CSDN，开始持续输出技术文章和真实 bug 修复经验。
• 2019 年 1 月：正式运营公众号，持续记录面试复盘、辅导案例和技术总结。
• 近两年：把面试与学习资料系统化整理，按关键字回复可领取，并持续更新迭代。

我看到的真实问题

辅导的人越多，我越清楚一个现实：

• 近几年入行人数越来越多，但不少人是“信息不对称 + 冲动入行”。
• 宣传里常常只讲成功样本，却不讲失败路径和真实成本。
• 找不到工作时，很多人会同时承受贷款、家庭和自我怀疑的多重压力。

这也是我一直坚持“讲真话、讲路径、讲代价”的原因。
我不希望你只看到“上岸截图”，却看不到“怎么从 0 到 1”。

故事与初心

我也曾在大四实习阶段频繁碰壁：大厂面试屡屡不过，能过的大多是外包岗位，一度想放弃。后来遇到前辈点醒我：刚起步时，尽量争取更高质量的平台经历，长期收益会非常大。

那段时间我连续加班到凌晨，技术、项目、表达、面试节奏都在被反复打磨。也正是在那个阶段，我在心里埋下一个念头：

如果未来我有能力，一定要拉后来者一把。

2017 年我在贴吧随手发的一篇面经意外火了，私信大量涌来：改简历、问项目、问面试。
我几乎每条都认真回复，但也很快遇到现实问题：大量“白嫖式咨询”占用了精力，真正需要帮助、但性格内向的人反而得不到有效支持。

所以后来我开始做有门槛的付费答疑与系统辅导。
目的不是“提高门槛”，而是把时间和精力更精准地放在真正需要帮助、愿意执行的人身上。

我现在在做什么

今天我依然在做三件事：

• 面试辅导：帮助你把知识点、项目表达、答题节奏打磨到可落地。
• 学习辅导：帮你制定可执行的阶段计划，减少无效努力。
• 案例沉淀：把真实辅导过程方法化，持续更新资料体系。

如果你正在迷茫，不用着急。
只要方向清晰、方法正确、执行到位，结果会慢慢向你靠近。

1、ES是什么，为什么要用ES
ES是一个开源的分布式搜索和分析引擎，它被设计用于快速、灵活地搜索和分析大量数据。
Elasticsearch提供出色的全文搜索能力，适用于需要对大量数据进行高效搜索和查询的应用场景，使用倒排索引技术，能够快速高效地执行文本搜索，支持模糊搜索等。可以用来解决使用数据库进行模糊搜索时存在的性能问题；
Elasticsearch能够提供实时的搜索和分析结果，适用于对数据的及时性有要求的场景;
支持多种数据类型，适用于处理不同结构和格式的数据，使其更灵活和通用;
和Mysql相比：
关系型数据库(如 MySQL)在大数据量下查询效率低下， 模糊匹配有可能导致全表扫描。
MySQL全文索引只支持CHAR，VARCHAR 或者 TEXT 字段类型，不支持分词器。
2、ES索引的构建
Elasticsearch采用Rest风格API，因此其API就是一次http请求，你可以用任何工具发起http请求。
可以通过RESTful API或相关的客户端库来操作创建索引。
创建索引的请求格式：
请求方式：PUT
请求路径：/索引库名
请求参数：json格式：
{
"settings": { //索引库的设置
"number_of_shards": 3, //分片数量
"number_of_replicas": 2 //副本数量
}
}3、ES为啥查询这么快
倒排索引：Elasticsearch使用倒排索引结构，这是一种能够快速定位文档的数据结构。倒排索引通过记录每个词项(terms)出现在哪些文档中来加速搜索。相比于传统的行式数据库存储结构，倒排索引在文本搜索场景中的性能更好。
分布式搜索引擎：Elasticsearch是一个分布式系统，可以在多个节点上运行。它将数据分成多个分片，每个分片可以独立运行在不同的节点上。这种分布式架构允许Elasticsearch并行处理查询请求，提高了查询的速度和扩展性。
近实时性：Elasticsearch提供近实时性的搜索，在数据变更后，查询操作几乎可以立即看到结果。这得益于Elasticsearch的刷新机制，使得文档变更能够迅速生效。
缓存机制：Elasticsearch在查询时使用缓存，包括字段数据缓存、过滤器缓存等。这有助于在相同的查询被重复执行时，避免重新计算相同的结果，提高了查询效率。
文档存储格式：Elasticsearch 使用 JSON 格式存储文档，这种结构化的存储方式便于索引和查询。JSON 的灵活性也使得 Elasticsearch 能够轻松处理不同类型的数据。
4、倒排索引
传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。 而倒排索引，恰恰相反，它是从词出发，记载这个词在哪些文章中存在。
倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。
lucene 从 4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：
空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
查询速度快。
5、ES中的数据和数据库同步的问题
同步双写：将数据写到 MySQL 时，同时将数据写到ES。缺点就是性能也比较差，还存在写入失败数据丢失的风险。
异步双写：使用MQ异步写入。但是引入了消息中间件，系统复杂性增加。
定时扫表：数据库的相关表增加一个字段为 timestamp 的字段，Mysql做正常的增删改操作，然后增加一个定时任务每隔一段时间扫描该表，把这段时间发生变化的数据提取出来写入到es。但是这种方法时效性比较差。
基于Binlog实时同步：监听binlog日志，从binlog日志中读取该表的日志信息，家那个变动的信息发送到MQ，然后消费消息写入到es。

回答提示：是一种比较通俗的解释，比较好理解，如果‘参考答案’不太好记住，可以直接复习回答提示也可以。
1、面向对象和面向过程的区别是什么？
回答提示：
面向过程就像是做菜时按步骤来，先洗菜、切菜、炒菜，一步步完成。它关注解决问题的步骤和流程，直接用函数实现每个步骤，然后依次调用。
而面向对象则更像是把做菜看成一个整体，关注构成这个问题的各个“对象”，比如“锅”、“铲子”、“食材”等。每个对象有自己的属性和行为（方法），如“锅”有“加热”的方法。面向对象通过创建对象并调用它们的方法来解决问题，更强调事物的属性和行为，以及它们之间的关系。
总结来说，面向过程更直接，关注怎么做；面向对象更抽象，关注做什么和由谁来做。面向对象具有更高的复用性、扩展性和维护性，但可能性能稍低；面向过程则性能较高，但复用和维护可能较复杂。
参考回答：
面向过程和面向对象是两种不同的处理问题的角度。
面向过程更注重事情的每一个步骤及顺序。主要是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用
面向对象更注重事情有哪些参与者（对象）、及各自需要做什么。主要是把事物对象化，包括其属性和行为。通过调用不同对象之间的方法，以组合的方式解决问题。
2、面向对象的三大基本特征
回答提示：
封装：就是把数据和操作数据的方法“打包”在一起，形成一个独立的单元（类）。外界不需要知道内部的具体实现细节，只需要通过接口（类提供的方法）与之交互。这就像是一个黑盒子，我们只知道它的输入和输出，但不知道里面是怎么工作的。
继承:子类可以继承父类的属性和方法，这样就可以在不需要重新编写原有代码的基础上，扩展新的功能。比如，我们可以定义一个“动物”类，然后让“猫”和“狗”类继承它，从而复用“动物”类中的属性和方法。
多态:是同一个接口（方法）在不同的子类中有不同的实现。这样，我们就可以用同一个父类类型的引用来调用不同子类的方法，实现不同的功能。这增加了程序的灵活性和可扩展性。
继承，方法重写，父类引用指向子类对象
父类类型 变量名 = new 子类对象 ;
变量名.方法名();
参考回答：
三大基本特征：封装、继承、多态。
封装
封装的意义，在于明确标识出允许外部使用的所有成员函数和数据项，提供对应的函数给外部进行调用，内部实现对外部调用不可见，外部调用无需修改或关心内部实现。
继承
继承基类的方法，并做出自己的改变和/或扩展，子类共性的方法或者属性直接使用父类的，而不需要自己再定义，只需扩展自己个性化的。
多态
基于对象所属类的不同，外部对同一个方法的调用，实际执行的逻辑不同，父类中定义的属性和方法被子类继承后或者接口定义的方法被子类实现，通过重写使得父类和子类具有不同的实现，从而同一个属性或方法在父类及其各个子类中具有不同的含义。无法调用子类特有的功能。
4、==和equals区别(了解)
回答提示：
==操作符：它主要用于比较基本数据类型的值是否相等，比如两个整数是否相等。对于引用数据类型，==比较的是两个对象的内存地址是否相同，即它们是否是同一个对象的引用。简单来说，==看的是“是不是同一个东西”。
equals方法：它是Object类的一个方法，用于比较两个对象的内容是否相等。默认情况下，equals方法的行为和==对于引用类型是一样的，即比较内存地址。但是，很多类（如String、Integer等）都重写了equals方法，使其能够比较对象的内容是否相等，而不是内存地址。简单来说，equals看的是“内容是否一样”。
参考回答：
==：对于基本数据类型，直接比较值；对于引用数据类型，比较引用（内存地址）。
equals()：首先检查两个对象是否为同一个对象的引用（这通常是通过==运算符完成的，但具体实现可能有所不同），如果不是，则根据类的具体实现来比较对象的内容。许多类（如String、Integer等）都重写了equals()方法以提供更有意义的比较逻辑。
5、equals() 既然已经能实现对比的功能了，为什么还要 hashCode() 呢？（了解）
回答提示：
想象一下你有一堆对象，你想要快速地找出里面是否有某个特定的对象。如果只用equals()方法逐个比较，效率会很低，因为equals()可能会比较对象的很多内部细节。
而hashCode()方法则是用来快速判断两个对象在逻辑上是否可能相等的一个“捷径”。如果两个对象的hashCode()值不同，那么根据hashCode()的设计原则，这两个对象在逻辑上一定不相等，我们甚至不需要调用equals()方法就可以知道结果。这样，我们可以先将对象存储或查找在基于哈希值的集合中（如HashSet、HashMap），大大减少了不必要的equals()调用，提高了效率。
hashCode()方法通过提供一个快速的初步判断，帮助我们缩小了可能相等的对象的范围，与equals()方法一起工作，实现了高效的对象比较和查找。
参考回答：
因为重写的 equals() 里一般比较的比较全面比较复杂，这样效率就比较低，而利用 hashCode() 进行对比，则只要生成一个 hash 值进行比较就可以了，效率很高，那么 hashCode() 既然效率这么高为什么还要 equal() 呢？
因为 hashCode() 并不是完全可靠，有时候不同的对象他们生成的 hashcode 也会一样（生成 hash 值得公式可能存在的问题），所以 hashCode() 只能说是大部分时候可靠，并不是绝对可靠，所以我们可以得出结论：
equals() 相等的两个对象他们的 hashCode() 肯定相等，也就是用 equals() 对比是绝对可靠的。
hashCode() 相等的两个对象他们的 equals() 不一定相等，也就是 hashCode() 不是绝对可靠的。
6、String、StringBuilder和StringBuffer的区别？
回答提示：
String是final修饰的，不可变，每次操作都会产生新的String对象.
StringBuffer是在原对象上操作，是线程安全的，是synchronized修饰的。
StringBuilder是在原对象上操作，是线程不安全的。
性能：StringBuilder ＞ StringBuffer ＞ String
参考回答：
字符串类型String是不可变的，即一旦创建后，其值不可被修改。相比之下，StringBuilder和StringBuffer是可变的，允许对其内容进行修改。其中，StringBuffer是线程安全的，而StringBuilder是非线程安全的。
7、String str=new String("IT枫斗者")创建了几个对象？
参考回答：
1个或者2个
new String("IT枫斗者");相信很多小伙伴们听到的答案很多，有说创建了1个对象，也有说创建了2个对象。答案对，也不对，关键是要知道问题底层的原理。
String str1 = "IT枫斗者"; // 在常量池中

String str2 = new String("IT枫斗者"); // 在堆上当直接赋值时，字符串“IT枫斗者”会被存储在常量池中，只有1份，此时的赋值操作等于是创建0个或1个对象。如果常量池中已经存在了“IT枫斗者”，那么不会再创建对象，直接将引用赋值给str1；如果常量池中没有“IT枫斗者”，那么创建一个对象，并将引用赋值给str1。
那么，通过new String(“IT枫斗者”);的形式又是如何呢？答案是1个或2个。
当JVM遇到上述代码时，会先检索常量池中是否存在“IT枫斗者"，IT枫斗者"这个字符串，则会先在常量池中创建这个一个字符串。然后再执行new操作，会在堆内存中创建一个存储“IT枫斗者”的String对象，对象的引用赋值给str2。此过程创建了2个对象。
当然，如果检索常量池时发现已经存在了对应的字符串，那么只会在堆内创建一个新的String对象，此过程只创建了1个对象。
8、接口和抽象类的区别？（最少要回答出1,2,3,5,7）
参考回答：

1. 定义与目的
   接口：是一种行为规范或约定，它定义了对象应该做什么，而不关心对象具体如何做。接口只包含方法的声明，不包含方法的实现。
   抽象类：是一种不能被实例化的类，它提供了一种模板，用于被其他类继承并实现其中的抽象方法。抽象类可以包含方法的实现，也可以不包含（即抽象方法）。
2. 成员变量
   接口：成员变量默认都是静态常量（static final），不能被修改。
   抽象类：可以包含字段、属性、方法（包括抽象方法和非抽象方法）、构造器等。
3. 方法
   接口：方法默认是公开的（public），且不能有具体实现（Java 8及之后允许接口定义默认方法和静态方法，但仍以抽象方法为主）。接口中的所有方法都是抽象的。
   抽象类：方法可以是抽象的，也可以是非抽象的。抽象方法没有具体实现，需要在子类中重写；非抽象方法可以有具体实现。抽象类中的方法可以有不同的访问级别。
4. 实例化
   接口：不能被实例化，它只能被类实现。
   抽象类：不能被直接实例化，但可以通过其子类（如果子类不是抽象的）来实例化。
5. 继承与实现
   接口：一个类可以实现多个接口，从而获取多个接口中的方法。这是接口实现多态性的一个重要方式。
   抽象类：一个类只能继承一个抽象类（在大多数面向对象的编程语言中，如Java）。这种单继承的特性限制了抽象类的使用范围。
6. 扩展性
   接口：具有很好的扩展性，可以很容易地添加新的方法，而不需要修改现有的实现类。
   抽象类：扩展性相对较差，如果添加新的抽象方法，所有子类都需要实现这个方法，这可能会影响到现有的代码。
7. 设计层面
   抽象类：是对类的抽象，是一种模板式设计。它对整个类进行抽象，包括属性和行为，子类必定是抽象类的一种类型，继承是“是不是”的关系。
   接口：是对行为的抽象，是一种辐射式设计。它是对类局部（行为）的抽象，接口实现是“有没有”的关系，比如一个类是否能实现某个接口，取决于它是否具备该接口所定义的行为
   9、浅拷贝和深拷贝？
   回答提示：
   浅拷贝仍然指向原始对象的内存地址。这意味着，如果原始对象中的子对象发生了变化，浅拷贝得到的对象也会受到影响。浅拷贝适用于对象结构较简单，不包含复杂数据结构或不需要独立修改子对象的情况。
   深拷贝递归地复制了对象内部的所有子对象或属性，创建全新的内存空间来存储这些对象。因此，深拷贝得到的对象与原始对象是完全独立的，对其中一个对象的修改不会影响到另一个对象。深拷贝适用于需要保持数据独立性和完整性的场景，如数据备份、多线程编程等。
   参考答案：
8. 定义与本质
   浅拷贝（Shallow Copy）：
   创建一个新对象，然后将当前对象的非静态字段复制到该新对象，如果字段是值类型的，那么对该字段执行逐位复制；如果字段是引用类型的话，则复制引用但不复制引用的对象。
   因此，原始对象及其副本引用同一个对象。
   BeanUtils.copyProperties方法用于将一个bean的属性值复制到另一个bean中，前提是这两个bean之间有相同的属性名和兼容的属性类型。这种方法在处理JavaBean之间的数据转换时非常有用，尤其是在不同层（如数据访问层和服务层）之间传递数据时。

1、JAVA 四种引用类型(了解)
强引用：
描述：强引用是我们最常见的引用类型，只要一个对象具有强引用，它就不会被垃圾回收器回收。
例子：
Object obj = new Object();在这个例子中，obj是一个强引用，指向Object的一个实例。只要obj还在使用，这个Object实例就不会被回收。
软引用：
描述：软引用是一种内存敏感的引用，如果一个对象只具有软引用，那么在内存空间不足时，垃圾回收器会考虑回收它。
例子：
SoftReference＜Object＞ softRef = new SoftReference＜＞(new Object());在这个例子中，softRef是一个软引用，指向一个Object实例。如果内存不足，这个实例可能会被回收。
弱引用：
描述：弱引用比软引用更加弱，它不足以阻止对象的垃圾回收。无论当前内存空间足够与否，只要垃圾回收器发现了只具有弱引用的对象，就会回收它。
例子：
WeakReference＜Object＞ weakRef = new WeakReference＜＞(new Object());在这个例子中，weakRef是一个弱引用，指向一个Object实例。无论内存空间如何，这个实例都可能被回收。
虚引用：
描述：虚引用是所有引用类型中最弱的一个。它无法阻止垃圾回收器的回收过程，也无法通过虚引用来获取对象的实例。它的主要作用是跟踪对象被垃圾回收的状态。
例子：
PhantomReference＜Object＞ phantomRef = new PhantomReference＜＞(new Object(), new ReferenceQueue＜＞());在这个例子中，phantomRef是一个虚引用，指向一个Object实例，并且关联了一个引用队列。这个实例随时可能被回收，而且回收时，phantomRef会被加入到关联的引用队列中。
2、类加载过程（按图顺序向面试官介绍，细节了解）

加载：加载是类加载过程中的一个阶段，这个阶段会在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的入口。注意这里不一定非得要从一个 Class 文件获取，这里既可以从 ZIP 包中读取（比如从 jar 包和 war 包中读取），也可以在运行时计算生成（动态代理），也可以由其它文件生成（比如将 JSP 文件转换成对应的 Class 类）。
验证 :这一阶段的主要目的是为了确保 Class 文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
准备:为类变量分配内存并设置类变量（是被static修饰的变量，变量不是常量，所以不是final的，就是static的）初始值的阶段。这些变量所使用的内存在方法区中进行分配。比如
private static int age = 26;

类变量age会在准备阶段过后为 其分配四个（int四个字节）字节的空间，并且设置初始值为0，而
不是26。
若是final的，则在编译期就会设置上最终值。解析：JVM会在此阶段把类的二进制数据中的符号引用替换为直接引用。
符号引用：符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。
直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有 了直接引用，那引用的目标必定已经在内存中存在。
初始化 ：初始化阶段是执行类构造器 ＜clinit＞() 方法的过程，到了初始化阶段，才真正开始执行类定义的Java程序代码（或者说字节码 ）。比如准备阶段的那个age初始值是0，到这一步就设置为26。
使用：对象都出来了，业务系统直接调用阶段。
卸载 ：用完了，可以被GC回收了。
3、类加载器种类以及加载范围

参考回答：
启动类加载器（Bootstrap ClassLoader）
最顶层类加载器，他的父类加载器是个null，也就是没有父类加载器。负责加载jvm的核心类库，比如 java.lang.* 等，从系统属性中的 sun.boot.class.path 所指定的目录中加载类库。他的具体实现由Java虚拟机底层C++代码实现。
扩展类加载器（Extension ClassLoader）
父类加载器是Bootstrap ClassLoader。从 java.ext.dirs 系统属性所指定的目录中加载类库， 或者从JDK的安装目录的 jre/lib/ext 子目录（扩展目录）下加载类库，如果把用户的jar文件放在这个目录下，也会自动由扩展类加载器加载。继承自 java.lang.ClassLoader 。
应用程序类加载器（Application ClassLoader）
父类加载器是Extension ClassLoader。从环境变量classpath或者系统属性 java.class.path 所指定的目录中加载类。继承自 java.lang.ClassLoader 。
自定义类加载器（User ClassLoader）
除了上面三个自带的以外，用户还能制定自己的类加载器，但是所有自定义的类加载器都应该继承自 java.lang.ClassLoader 。比如热部署、tomcat都会用到自定义类加载器。
4、双亲委派是什么？

参考回答：
当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父 类去完成，每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中， 只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的 Class），子类加载器才会尝试自己去加载。
采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载 器最终得到的都是同样一个 Object 对象。
5、如何破坏双亲委派模型 （了解）
参考回答：
重写loadClass方法
背景：在JDK 1.2之前，Java就已经存在类加载器和ClassLoader抽象类，但双亲委派模型是在JDK 1.2中引入的。为了兼容旧代码，JDK 1.2中的ClassLoader类允许用户重写loadClass方法来实现自定义的类加载逻辑，这导致了双亲委派模型的第一次“被破坏”。
实现方式：通过继承ClassLoader抽象类并重写其loadClass方法，可以在类加载过程中自定义委派逻辑，从而实现打破双亲委派模型。但需要注意的是，JDK官方并不推荐这种方式，因为它可能会破坏Java程序的稳定性和安全性。
使用线程上下文类加载器（Thread Context ClassLoader）
背景：在某些情况下，顶层类加载器（如启动类加载器）加载的类可能需要调用由用户自定义类加载器加载的类。例如，JDBC驱动接口（java.sql.Driver）是由启动类加载器加载的，但其具体实现则是由数据库厂商提供的，并由应用类加载器加载。为了解决这种跨类加载器的调用问题，Java引入了线程上下文类加载器。
实现方式：通过java.lang.Thread类的setContextClassLoader()方法可以设置当前线程的上下文类加载器。当需要加载某些特定类时，可以使用线程上下文类加载器来加载，而不是遵循双亲委派模型。这种方式在Java SPI（服务提供接口）机制中得到了广泛应用。
其他框架和中间件的实现
在一些特定的框架和中间件中（如Tomcat、OSGi等），为了实现特定的功能（如热部署、模块化等），它们也采用了打破双亲委派模型的方式。这些框架和中间件通常会对类加载器进行扩展和定制，以满足其特殊需求。
6、JVM内存结构

参考回答：
程序计数器(线程私有)
一块较小的内存空间, 是当前线程所执行的字节码的行号指示器，每条线程都要有一个独立的程序计数器，这类内存也称为“线程私有”的内存。
正在执行 java 方法的话，计数器记录的是虚拟机字节码指令的地址（当前指令的地址）。如果还是 Native 方法，则为空。
这个内存区域是唯一一个在虚拟机中没有规定任何 OutOfMemoryError 情况的区域。
虚拟机栈(线程私有)

是描述java方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
栈帧（ Frame）是用来存储数据和部分过程结果的数据结构，同时也被用来处理动态链接 (Dynamic Linking)、 方法返回值和异常分派（ Dispatch Exception）。栈帧随着方法调用而建，随着方法结束而销毁——无论方法是正常完成还是异常完成（抛出了在方法内未被捕获的异常）都算作方法结束。
本地方法区(线程私有)
本地方法区和 Java Stack 作用类似, 区别是虚拟机栈为执行 Java 方法服务, 而本地方法栈则为Native 方法服务, 如果一个 VM 实现使用 C-linkage 模型来支持 Native 调用, 那么该栈将会是一个C 栈，但 HotSpot VM 直接就把本地方法栈和虚拟机栈合二为一。
堆（Heap-线程共享）-运行时数据区
是被线程共享的一块内存区域，创建的对象和数组都保存在 Java 堆内存中，也是垃圾收集器进行垃圾收集的最重要的内存区域。由于现代 VM 采用分代收集算法, 因此 Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代。
方法区/永久代（线程共享）
也称非堆，用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。是被所有线程共享的，会发生OOM。
运行时常量
是方法区的一部分，存常量（比如static final修饰的，比如String 一个字符串）和符号引用。是被所有线程共享的，会发生OOM。
7、判断对象是否能被回收的算法
参考回答：
引用计数法
给对象添加一个引用计数器，每当有一个地方引用他的时候该计数器的值就+1，当引用失效的时候该计数器的值就-1；当计数器的值为0的时候，jvm判定此对象为垃圾对象。存在内存泄漏的bug，比如循环引用的时候，所以jvm虚拟机采取的是可达性分析法。
可达性分析法
有一些根节点GC Roots作为对象起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链，当一个对象到GC Roots没有任何引用链相连的时候，则证明此对象为垃圾对象。
补充：哪些可作为GC Roots？
虚拟机栈中的引用的对象
方法区中的类静态属性引用的对象
方法区中常量引用的对象
本地方法栈中JNI（native方法）引用的对象
8、JVM 运行时内存
参考回答：

Java 堆从 GC 的角度还可以细分为: 新生代(Eden 区、From Survivor 区和 To Survivor 区)和老年代。
其中新生代(Young) 被分为 Eden和S0（from)和S1(to)。 默认情况下Edem : from : to = 8 : 1 : 1 ，此比例可以通过 –XX:SurvivorRatio 来设定
新生代
是用来存放新生的对象。一般占据堆的 1/3 空间。由于频繁创建对象，所以新生代会频繁触发MinorGC 进行垃圾回收。新生代又分为 Eden 区、ServivorFrom、ServivorTo 三个区。
Eden 区：Java 新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老 年代）。当 Eden 区内存不够的时候就会触发 MinorGC，对新生代区进行一次垃圾回收。
ServivorFrom：上一次 GC 的幸存者，作为这一次 GC 的被扫描者。
ServivorTo：保留了一次 MinorGC 过程中的幸存者。
老年代
主要存放应用程序中生命周期长的内存对象。
老年代的对象比较稳定，所以 MajorGC 不会频繁执行。在进行 MajorGC 前一般都先进行 了一次 MinorGC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次 MajorGC 进行垃圾回收腾出空间。
MajorGC 采用标记清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没 有标记的对象。MajorGC 的耗时比较长，因为要扫描再回收。MajorGC 会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配。当老年代也满了装不下的时候，就会抛出 OOM（Out of Memory）异常。
元空间
元空间（Metaspace）是Java虚拟机（JVM）用于存储类元数据（如类的结构、方法信息等）的内存区域，从Java 8开始取代了永久代（PermGen）。与PermGen不同，元空间不再位于Java堆内存中，而是使用本地内存（Native Memory），这使得其大小不再受限于Java堆的大小，可以根据需要动态扩展。元空间支持类元数据的垃圾回收，当类被卸载时，其对应的元数据也会被回收，从而提高内存利用率。通过配置参数如-XX:MetaspaceSize和-XX:MaxMetaspaceSize，可以调整元空间的初始大小和最大容量，以优化应用程序的内存管理。元空间的引入有效解决了PermGen区域容易因类加载过多而导致内存溢出的问题，提升了JVM的稳定性和灵活性。
9、MinorGC 的过程（复制-＞清空-＞互换，新生代）
参考回答：
MinorGC 采用复制算法。
eden、servicorFrom 复制到 ServicorTo，年龄+1：首先，把 Eden 和 ServivorFrom 区域中存活的对象复制到 ServicorTo 区域（如果有对象的年龄以及达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1（如果 ServicorTo 不够位置了就放到老年区）；
清空 eden、servicorFrom ：然后，清空 Eden 和 ServicorFrom 中的对象；
ServicorTo 和 ServicorFrom 互换：最后，ServicorTo 和 ServicorFrom 互换，原 ServicorTo 成为下一次 GC 时的 ServicorFrom区。
10、为什么把堆栈分成两个？（了解）
参考回答：
栈代表了处理逻辑，堆代表了存储数据，分开后逻辑更清晰，面向对象模块化思想。栈是线程私有，堆是线程共享区，这样分开也节省了空间，比如多个栈中的地址指向同一块堆内存中的对象。
栈是运行时的需要，比如方法执行到结束，栈只能向上增长，因此会限制住栈存储内容的能力，而堆中的对象是可以根据需要动态增长的。
11、简述下对象的分配规则（了解）
参考回答：
对象优先分配在Eden区，如果Eden区没有足够的空间时，虚拟机执行一次YGC。并将还活着的对象放到from/to区，若本次YGC后还是没有足够的空间，则将启用分配担保机制在老年代中分配内存。
大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。这样做的目的是避免在 Eden区和两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。
长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄计数器，如果对象经过了1次YGC那么对象会进入Survivor区，之后每经过一次YGC那么对象的年龄加1，直到达到阀值对象进入老年区。默认阈值是15。可以通过 -XX:MaxTenuringThreshold 参数来设置。
动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一 半，年龄大于或等于该年龄的对象可以直接进入老年代。无需等到 -XX:MaxTenuringThreshold 参数要求的年龄。
空间分配担保。每次进行YGC时，JVM会计算Survivor区移至老年区的对象的平均大小，如果这个值大于老年区的剩余值大小则进行一次Full GC，如果小于检查HandlePromotionFailure设置，如果true则只进行YGC，如果false则进行Full GC。
12、CMS 收集器（多线程标记清除算法，老年代）
参考回答：

CMS 工作机制相比其他的垃圾收集器来说更复杂，整个过程分为以下 4 个阶段：
初始标记：只是标记一下 GC Roots 能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
并发标记 ：进行 GC Roots 跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
重新标记：为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
并发清除：清除 GC Roots 不可达对象，和用户线程一起工作，不需要暂停工作线程。由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS 收集器的内存回收和用户线程是一起并发地执行。
所以CMS的优点是：
并发高
停顿低
STW时间短。
缺点：
对cpu资源非常敏感（并发阶段虽然不会影响用户线程，但是会一起占用CPU资源，竞争激烈的话会导致程序变慢）。
无法处理浮动垃圾，当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，失败后而导致另一次Full GC的产生，由于CMS并发清除阶段用户线程还在运行，伴随程序的运行自然会有新的垃圾产生，这一部分垃圾是出现在标记过程之后的，CMS无法在本次去处理他们，所以只好留在下一次GC时候将其清理掉。
内存碎片问题（因为是标记清除算法）。当剩余内存不能满足程序运行要求时，系统将会出现 Concurrent Mode Failure，临时 CMS 会采用 Serial Old 回收器进行垃圾清除，此时的性能将会被降低。
13、三色标记算法（了解）
这个算法基于图论中的图染色问题，通过给对象标记三种不同的颜色来表示其垃圾回收的状态。
这三种颜色是：
白色： 表示对象还没有被访问过，即未被扫描和标记。
灰色： 表示对象已经被扫描和标记，但其引用对象还没有被扫描。
黑色： 表示对象及其引用对象都已经被扫描和标记。
三色标记算法的基本思想是通过多次迭代的方式，通过不同的阶段标记不同颜色的对象，最终达到全局标记的目的。主要步骤：
初始标记阶段： 在这个阶段，只标记根对象为灰色，并且只扫描根对象的直接引用，标记它们为灰色。这个阶段是短暂的，通常需要停顿。
并发标记阶段： 在这个阶段，垃圾收集器与用户线程并发执行。从灰色对象开始，递归扫描其引用，标记为灰色，并将其引用的对象标记为灰色。这个阶段会持续直到灰色对象为空。
重新标记阶段： 在并发标记阶段结束后，可能有新的对象产生，因此需要重新标记一遍。在这个阶段，垃圾收集器会停顿，标记所有的存活对象，将灰色对象标记为黑色。
清理阶段： 在这个阶段，清理掉白色的对象，即那些没有被访问到的对象，将它们释放掉
14、G1垃圾回收器（了解）
G1（Garbage First）在JDK7中加入JVM，在JDK9中成为了默认的垃圾收集器，如果在JDK8中使用G1，我们可以使用参数 -XX:+UseG1GC 来开启。
在G1之前的垃圾回收器，如Parallel Scavenge、Parallel Old、CMS等，主要针对Java堆内存中的特定部分(新生代或老年代)进行操作。然而，G1将Java堆内存划分为多个大小相等的区域(Region)，并根据每个区域中垃圾对象的数量和大小来优先进行垃圾回收；G1这种基于Region回收的方式，可以预测停顿时间。
G1会根据每个Region里面垃圾“价值”的大小，在后台维护一个优先级列表，每次根据用户设定的允许收集停顿的时间 (-XX:MaxGCPauseMilis,默认为200毫秒)优先处理价值收益最大的Region。
15、CMS垃圾回收器和G1垃圾回收器对比（了解）
因为CMS是基于标记-清除的算法实现的，所以CMS会有空间碎片化的问题。而在G1收集器上是不存在的，G1从整体上来看是基于标记-整理算法实现，从Region之间又是基于标记-复制算法实现的。
由于G1不会产生空间碎片，可以为对象的分配提供更规整的内存。此外还避免了由于分配大对象时找不到连续的内存空间，而不得不提前触发下一次垃圾回收。
由于跨Region引用等大量双向卡表的存在，G1收集器比CMS(只需要处理老年代到新生代的引用)占用更多的内存，
CMS收集器使用写后屏障来更新维护卡表，而G1收集器除了使用写后屏障维护卡表，为了实现SATB的算法，还需要使用写前屏障来跟踪并发时指针变化情况。所以G1收集器会增加程序运行时的额外负载。
16、大型项目如何进行性能瓶颈调优（了解）
参考回答：
数据库与SQL优化：一般dba负责数据库优化，比如集群主从等。研发负责SQL优化，比如索引、分库分表等。
集群优化：一般OP负责，让整个集群可以很容易的水平扩容，再比如tomcat/nginx的一些配置优化等。
硬件升级：选择最合适的硬件，充分利用资源。
代码优化：很多细节，可以参照阿里巴巴规范手册和安装sonar插件这种检测代码质量的工具。也可以适当的运用并行，比如CountDownLatch等工具。
jvm优化：内存区域大小设置、对象年龄达到次数晋升老年代参数的调整、选择合适的垃圾收集器以及合适的垃圾收集器参数、打印详细的GC日志和oom的时候自动生成dump。
操作系统优化
17、系统内存飙高，如何查找问题？
参考回答：
找出哪个进程内存占用高（top命令）
查看jvm进程号（jps命令）
导出堆内存 (jmap命令生成dump文件，注意：线上系统，内存特别大，jmap执行期间会对进程产生很大影响，甚至卡顿，所以操作前最好先从负载均衡里摘掉。)
分析dump文件 (比如mat软件)
18、常用的调优工具有哪些？（了解）
参考回答：
JDK内置的命令行：jps（查看jvm进程信息）、jstat（监视jvm运行状态的，比如gc情况、jvm内存情况、类加载情况等）、jinfo（查看jvm参数的，也可动态调整）、jmap（生成dump文件的，在dump的时候会影响线上服务）、jhat（分析dump的，但是一般都将dump导出放到mat上分析）、jstack（查看线程的）。
JDK内置的可视化界面：JConsole、VisualVM，这两个在QA环境压测的时候很有用。
阿里巴巴开源的arthas：神器，线上调优很方便，安装和显示效果都很友好。
19、GC常用参数（了解）
参考回答：
堆设置：
-Xms：设置堆的初始大小。
-Xmx：设置堆的最大大小。
栈设置：
-Xss：设置每个线程的栈大小。
垃圾回收器设置：
-XX:+UseG1GC：使用 G1 垃圾回收器。
-XX:+UseParallelGC：使用并行垃圾回收器。
性能调优：
-XX:PermSize 和 -XX:MaxPermSize：在 Java 8 之前设置永久代的初始大小和最大大小。
-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize：在 Java 8 及以上版本设置 Metaspace 的初始大小和最大大小。
-XX:+PrintGCDetails：打印垃圾回收的详细信息。
调试和分析：
-verbose:gc：输出垃圾回收的详细信息。
-XX:+HeapDumpOnOutOfMemoryError：在内存溢出时生成堆转储。
20、YoungGC和FullGC的触发条件是什么？（了解）
参考回答：
Young GC和Full GC的触发条件在Java虚拟机（JVM）中有一些差异。以下是它们的主要触发条件：
Young GC的触发条件：
时间间隔：可以通过-XX:MaxGCPauseMillis设定的时间间隔来触发Young GC。
堆大小：当Young GC的堆大小超过设定的目标大小时，Young GC会被触发。
频繁的Minor GC：当连续发生许多次Minor GC时，Full GC可能会被触发。
Eden区可用内存不足：Eden区是Young Generation的一部分，当Eden区的可用内存不足时，Young GC会被触发。
Full GC的触发条件：
老年代达到某一阈值：老年代（Old Generation）的堆内存使用率达到某一阈值（默认是92%）时，会触发Full GC。
方法区可用内存不足：方法区（PermGen space或Metaspace）的可用内存不足时，也会触发Full GC。在Java 8及之后的版本中，PermGen space已经被Metaspace所取代。
旧生代空间不足：当新生代对象转入及创建为大对象、大数组时，旧生代空间可能会出现不足的现象。如果执行Full GC后空间仍然不足，JVM会抛出java.lang.OutOfMemoryError: Java heap space错误。
Permanet Generation空间满：Permanet Generation中存放的是一些class的信息等。当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，从而触发Full GC。
21、Java中的类什么时候会被加载？（了解）
参考回答：
创建类的实例：当通过new关键字创建一个类的实例时，该类会被加载。
访问类的静态变量、静态方法或静态初始化块：当程序首次主动使用某个类或接口的静态变量，或者对该静态变量进行赋值，或者调用类的静态方法时，Java虚拟机就会加载这个类到内存中。此外，类的静态初始化块也会在类加载的时候被执行。
通过反射加载类：使用Java的反射API（如Class.forName()）也可以触发类的加载。
初始化类的子类：在初始化一个类的子类之前，其父类必须先被加载。
使用类加载器显式加载：通过类加载器（ClassLoader）的loadClass()方法，可以显式地加载指定的类。
JVM启动时被标记为需要启动的类：在JVM启动时，会加载一些特殊的类，这些类在Java虚拟机的启动过程中就被标记为需要启动的类。
Java的类加载器采用了双亲委派模型（Parents Delegation Model）。当一个类加载器需要加载一个类时，它首先会把这个请求委派给父类加载器去完成，每一层的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。这种机制保证了Java核心类库的类型安全，防止了核心API被篡改。
22、为什么基本类型不放在堆里（了解）
参考回答：
因为基本类型占用的空间一般都是1-8个字节（所需空间很少），而且因为是基本类型，所以不会出现动态增长的情况（长度是固定的），所以存到栈上是比较合适的。反而存到可动态增长的堆上意义不大。
23、JVM调优（先了解，后面需要结合项目）
参考回答：
JVM的调优是为了优化应用程序的性能、资源利用率以及响应时间。调优的目标包括减小垃圾回收停顿时间、提高吞吐量、降低内存消耗等。实际中，要根据业务的实际情况去调整和优化。
使用JVM监控工具，如VisualVM、JConsole、Mission Control等，对应用程序进行性能分析。通过查看内存使用情况、垃圾回收统计、线程活动等信息，找到性能瓶颈和潜在问题。
启用GC日志并分析日志文件。GC日志包含了垃圾回收的详细信息，可以了解各种垃圾回收事件的发生时间、停顿时间、频率等。通过分析GC日志，可以确定是否需要调整垃圾回收器的类型、内存大小等参数。
在应用程序出现内存泄漏或者内存占用过高时，获取Heap Dump并分析。Heap Dump是一个内存快照，可以帮助你查找对象的引用链，找到内存泄漏的根本原因。
调整堆大小： 根据性能分析的结果，调整堆内存的大小。可以通过调整-Xms和-Xmx参数来设置堆的初始大小和最大大小，以及通过-Xmn参数来设置新生代大小。
选择垃圾回收器： 根据应用程序的特性，选择合适的垃圾回收器。例如，对于响应时间敏感的应用，可以选择G1垃圾回收器。
调整垃圾回收器参数： 根据GC日志的分析，调整垃圾回收器的相关参数。例如，可以通过-XX:MaxGCPauseMillis设置最大垃圾回收停顿时间，通过-XX:GCTimeRatio设置垃圾回收时间与应用执行时间的比率等。
代码优化： 通过代码审查和性能测试，对应用程序进行优化，避免不必要的资源消耗和垃圾回收压力。特别注意避免创建过多的临时对象。

什么是消息中间件？（了解）
消息中间件是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统。
消息中间件利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。
Kafka是什么？有什么作用？（了解）
Kafka 是一个分布式的流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流数据处理等多种特性而被广泛使用

主要功能体现于三点：
消息系统：kafka与传统的消息中间件都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，kafka还提供了大多数消息系统难以实现的消息顺序性保障及回溯性消费的功能。
存储系统：kafka把消息持久化到磁盘，相比于其他基于内存存储的系统而言，有效的降低了消息丢失的风险。这得益于其消息持久化和多副本机制。也可以将kafka作为长期的存储系统来使用，只需要把对应的数据保留策略设置为“永久”或启用主题日志压缩功能。
流式处理平台：kafka为流行的流式处理框架提供了可靠的数据来源，还提供了一个完整的流式处理框架，比如窗口、连接、变换和聚合等各类操作。
Kafka中有哪几个组件?
主题：Kafka主题是一堆或一组消息。
生产者：在Kafka，生产者发布通信以及向Kafka主题发布消息。
消费者：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。
经纪人：在管理主题中的消息存储时，我们使用Kafka Brokers。
Kafka Replicas是怎么管理的？（了解）

AR:分区中的所有 Replica 统称为 AR
ISR:所有与 Leader 副本保持一定程度同步的Replica(包括 Leader 副本在内)组成 ISR
OSR:与 Leader 副本同步滞后过多的 Replica 组成了 OSR
Leader 负责维护和跟踪 ISR 集合中所有 Follower 副本的滞后状态，当 Follower 副本落后过多时，就会将其放入 OSR 集合，当 Follower 副本追上了 Leader 的进度时，就会将其放入 ISR 集合。
默认情况下，只有 ISR 中的副本才有资格晋升为 Leader。
kafka的消费者是pull(拉)还是push(推)模式，这种模式有什么好处？
Kafka 遵循了一种大部分消息系统共同的传统的设计：producer 将消息推送到 broker，consumer 从broker 拉取消息。
优点：pull模式消费者自主决定是否批量从broker拉取数据，而push模式在无法知道消费者消费能力情况下，不易控制推送速度，太快可能造成消费者奔溃，太慢又可能造成浪费。
缺点：如果 broker 没有可供消费的消息，将导致 consumer 不断在循环中轮询，直到新消息到到达。为了避免这点，Kafka 有个参数可以让 consumer阻塞知道新消息到达(当然也可以阻塞知道消息的数量达到某个特定的量这样就可以批量发送)。
kafka维护消息状态的跟踪方法（了解）
Kafka中的Topic 被分成了若干分区，每个分区在同一时间只被一个 consumer 消费。然后再通过offset进行消息位置标记，通过位置偏移来跟踪消费状态。相比其他一些消息队列使用“一个消息被分发到consumer 后 broker 就马上进行标记或者等待 customer 的通知后进行标记”的优点是，避免了通信消息发送后，可能出现的程序奔溃而出现消息丢失或者重复消费的情况。同时也无需维护消息的状态，不用加锁，提高了吞吐量。
kafka判断一个节点还活着的有那两个条件？
节点必须维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久
讲一讲 kafka 的 ack 的三种机制
request.required.acks 有三个值 0 1 -1(all)，具体如下：
0：生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据。
1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader挂掉后他不确保是否复制完成新 leader 也会导致数据丢失。
-1(all)：服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的ack，这样数据不会丢失。
kafka 分布式（不是单机）的情况下，如何保证消息的顺序消费?
Kafka 中发送 1 条消息的时候，可以指定(topic, partition, key) 3 个参数，partiton 和 key 是可选的。
Kafka 分布式的单位是 partition，同一个 partition 用一个 write ahead log 组织，所以可以保证FIFO 的顺序。不同 partition 之间不能保证顺序。因此你可以指定 partition，将相应的消息发往同 1个 partition，并且在消费端，Kafka 保证1 个 partition 只能被1 个 consumer 消费，就可以实现这些消息的顺序消费。
另外，你也可以指定 key（比如 order id），具有同 1 个 key 的所有消息，会发往同 1 个partition，那这样也实现了消息的顺序消息。
kafka 如何不消费重复数据？比如扣款，我们不能重复的扣。
幂等性生产者：使用Kafka的幂等性生产者功能，确保即使发送多次，消息也只被记录一次。这通过唯一的生产者ID和序列号实现，防止了生产端的重复。
事务支持：Kafka事务特性允许生产者确保消息要么全部成功提交，要么全部失败回滚，适用于需要精确一次性处理的操作。
消费者端幂等处理：设计消费逻辑，使其对重复消息具有幂等性，如使用唯一键去重或数据库的唯一键约束，确保重复消息处理结果一致。
手动提交Offset：消费者处理消息后手动提交Offset，确保只有在消息被成功处理后才更新消费位置，避免未提交Offset导致的重复消费。
partition的数据文件（offffset，MessageSize，data）（了解）
partition的数据文件是存储消息的核心结构，每个数据文件主要包含三个关键元素：offset、MessageSize和data。
offset：这是消息在partition中的唯一标识符，类似于消息的“序号”或“位置”。offset是一个64位的长整型数值，用于确保消息的顺序性和定位能力。消费者可以通过指定offset来精确地找到分区中的某条消息，或者从某个位置开始消费消息。
MessageSize：这个字段记录了消息内容data的大小，即消息体的字节长度。通过MessageSize，Kafka可以快速地跳过或定位到消息体的起始位置，提高消息处理的效率。
data：这是消息的实际内容，可以是文本、JSON、二进制数据等任何格式。data字段存储了生产者发送到Kafka的具体信息，消费者通过读取这些数据来进行后续处理。
在Kafka中，partition被划分为多个segment文件，每个segment文件包含一定数量的消息。这些文件以顺序读写的方式进行操作，提高了磁盘利用率和读写性能。同时，Kafka为每个segment文件建立了索引文件，通过稀疏索引的方式记录了消息的offset和其在物理文件中的位置，进一步加速了消息的查找速度。
kafka如何实现数据的高效读取？（顺序读写、分段命令、二分查找）
Kafka实现数据的高效读取主要依赖于其独特的设计，包括顺序读写、分段存储和二分查找等机制。具体来说：
顺序读写：Kafka采用顺序写入的方式，新消息会被追加到已有消息的末尾。这种写入模式减少了磁盘I/O操作的随机访问，大大提高了写入效率。同样，读取时也是顺序读取，这与磁盘的物理特性相契合，进一步提升了读取性能。
分段存储：Kafka将每个partition划分为多个segment，每个segment包含固定大小的数据和对应的索引文件。这样设计避免了管理大文件的复杂性，同时方便了对旧数据的清理。每个segment文件独立存储，使得数据管理和维护更加高效。
二分查找：Kafka为每个segment维护了一个索引文件，其中存储了消息的offset和物理位置的映射关系。当需要查找特定offset的消息时，Kafka会利用二分查找算法在索引文件中快速定位消息所在的segment和数据文件中的具体位置，从而实现了高效的数据访问。
此外，Kafka还通过内存缓存、消息压缩等技术手段进一步提升了数据的读取效率。内存缓存使得Kafka可以将索引文件的部分内容保留在内存中，加速查找操作；而消息压缩则减少了磁盘和网络带宽的使用，使得数据在传输和存储时更加高效。
Kafka 消费者端的 Rebalance 操作什么时候发生？（了解）
在Kafka中，消费者端的Rebalance操作主要发生在以下几种情况，以确保消费者组能够公平且高效地分配订阅主题的分区：
消费者组成员变化：当有新消费者加入消费者组或现有消费者离开（无论是正常关闭、崩溃还是长时间未发送心跳被判定为“死亡”）时，会触发Rebalance。这是因为消费者组的成员变化可能导致分区分配不再均衡。
订阅主题分区数变化：如果消费者组订阅的任一主题的分区数发生变化（如分区增加或减少），也会触发Rebalance。这是为了根据新的分区情况重新分配消费者与分区之间的关系。
消费者组订阅变化：当消费者组订阅的主题列表发生变化，比如消费者取消了对某些主题的订阅，同样可能引发Rebalance。
协调者故障或变化：负责管理消费者组的协调者（Coordinator）如果发生故障，或者消费者组被重新分配给了另一个协调者，也可能触发Rebalance。
Rebalance过程是一个协调消费者组内成员重新分配分区的过程，它确保了消费者组能够动态地适应变化，保持高效的消息处理能力。然而，频繁的Rebalance可能会对性能产生负面影响，因此在设计和使用Kafka时，需要合理设置相关参数和配置，以减少不必要的Rebalance操作。
Kafka的那些设计让它有如此高的性能?
顺序写入与零拷贝技术：与传统的数据库系统不同，Kafka采用顺序写入的方式，这大大减少了磁盘寻道时间，提高了写入性能。同时，Kafka利用零拷贝技术，减少了数据传输过程中CPU和内存的开销，进一步提升了性能。
分区与副本机制：Kafka将数据分散到多个分区中，每个分区都可以独立处理数据写入和读取请求，充分利用了集群的计算和存储能力。同时，每个分区都有多个副本，既保证了数据的可靠性，又通过异步复制方式减少了数据同步的开销。
批量操作与压缩：Kafka支持批量写入和压缩功能，批量写入减少了网络传输和磁盘IO的次数，而压缩功能则降低了磁盘存储空间的使用，并减少了数据传输的开销。
高效的消费者组机制：消费者组允许多个消费者并行地消费同一个分区的消息，提高了并发处理能力。同时，Kafka支持多种消费模式，如发布订阅模式和队列模式，以适应不同的业务需求。
可扩展的架构：Kafka的分布式架构可以轻松通过添加更多的节点来扩展处理能力。这种水平扩展的能力使得Kafka能够应对大规模数据处理和实时流处理场景。
Kafka为什么不支持读写分离？
设计哲学：Kafka的设计目标是高吞吐量、低延迟和可扩展性。它采用发布-订阅模型，通过单一的Broker集群处理读写请求，这种架构简洁高效，避免了读写分离带来的复杂性。
数据一致性：在读写分离架构中，主从数据库之间存在复制延迟，这可能导致读操作读取到过时的数据，从而影响数据一致性。而Kafka通过分区和副本机制确保数据的一致性和可靠性，每个分区有多个副本，其中一个副本作为领导者处理读写请求，其他副本作为追随者同步数据，这种设计保证了数据的强一致性。
性能考量：Kafka已经通过优化读写性能来满足实时数据流处理的需求。在Kafka中，读写操作通常是连续的，且读取操作的性能已经非常高。因此，引入读写分离并不会显著提升Kafka的性能，反而可能增加系统的复杂性。
适用场景：Kafka主要用于实时数据流处理和日志聚合等场景，这些场景通常对数据的一致性和可靠性要求较高。读写分离架构更适合于读取密集型的应用场景，如在线事务处理系统，与Kafka的适用场景不完全匹配。
分区Leader选举策略有几种？
默认选举策略：Kafka默认采用一种基于ISR（In-Sync Replicas，同步副本集）的选举策略。当Leader副本故障时，Kafka会从ISR中选择一个新的副本作为Leader。通常，这个新Leader是具有最高偏移量（即数据最“领先”的副本），以保证数据的一致性和可靠性。
ISR优先选举：这是一种优化策略，旨在提高ISR中副本被选举为Leader的概率。在选举过程中，Kafka会优先考虑ISR中的副本，只有当ISR副本不可用或数量不足时，才会考虑其他副本。这种方式有助于减少选举成本和延迟，提升分区性能。
自定义选举策略：虽然Kafka没有直接提供多种预定义的选举策略供用户选择，但用户可以根据自己的需求和场景，通过实现自定义的选举逻辑来灵活应对特定情况。自定义选举策略可以根据副本的状态、健康状况、负载情况等因素进行决策，以满足分布式系统的特定需求。
请简述下你在哪些场景下会选择 Kafka？
实时数据流处理：Kafka擅长处理大规模、高吞吐量的实时数据流。当需要实时收集、处理和分析大量数据时，比如日志聚合、监控数据、用户行为追踪等，Kafka是一个理想的选择。
微服务间通信：在微服务架构中，服务间需要高效、可靠的通信机制。Kafka作为消息中间件，可以提供解耦、异步和可靠的通信方式，帮助微服务实现松耦合和高内聚。
事件驱动架构：Kafka支持事件驱动架构，允许系统根据事件进行响应和处理。这对于需要实时处理事件、触发后续操作或进行复杂工作流协调的应用场景非常有用。
日志和数据湖：Kafka可以作为日志和数据湖的存储引擎，为大数据分析、机器学习等提供数据源。它的顺序存储和高效读取特性使得处理大规模数据变得更加容易和高效。
分布式系统的消息总线：在需要构建分布式系统的消息总线时，Kafka可以提供高可用、可扩展和容错的消息传递服务，确保系统组件之间的通信畅通无阻。
请谈一谈 Kafka 数据一致性原理
副本机制：每个分区的数据都会被复制到多个副本中，包括一个领导者副本和多个追随者副本。所有读写操作都由领导者副本处理，追随者副本则从领导者副本同步数据。这种方式确保了数据的高可用性和容错性。
ISR列表：ISR是指与领导者副本保持同步的副本集合。只有处于ISR中的副本才能参与到消息的写入和读取过程中。当某个副本与领导者副本的同步延迟超过一定阈值后，就会被踢出ISR，直到同步恢复正常。这样可以确保只有可靠的副本参与到数据的读写操作，提高数据的一致性和可靠性。
幂等性和事务性：Kafka还引入了幂等性机制来确保消息的精确一次传递，通过生产者ID和序列号来实现。同时，Kafka支持事务性操作，允许生产者发送一批消息作为一个事务，确保这批消息要么全部成功，要么全部失败，进一步保障了数据的一致性和可靠性。
生产者发送消息有哪些模式？
发后即忘（fire-and-forget）:它只管往 Kafka 里面发送消息，但是不关心消息是否正确到达，这种方式的效率最高，但是可靠性也最差，比如当发生某些不可充实异常的时候会造成消息的丢失
同步（sync）:producer.send()返回一个Future对象，调用get()方法变回进行同步等待，就知道消息是否发送成功，发送一条消息需要等上个消息发送成功后才可以继续发送
异步（async）:Kafka支持 producer.send() 传入一个回调函数，消息不管成功或者失败都会调用这个回调函数，这样就算是异步发送，我们也知道消息的发送情况，然后再回调函数中选择记录日志还是重试都取决于调用方
发送消息的分区策略有哪些？

1.轮询：依次将消息发送该topic下的所有分区，如果在创建消息的时候 key 为 null，Kafka 默认采用这种策略。
2.key 指定分区：在创建消息是 key 不为空，并且使用默认分区器，Kafka 会将 key 进行 hash，然后根据hash值映射到指定的分区上。这样的好处是 key 相同的消息会在一个分区下，Kafka 并不能保证全局有序，但是在每个分区下的消息是有序的，按照顺序存储，按照顺序消费。在保证同一个 key 的消息是有序的，这样基本能满足消息的顺序性的需求。但是如果 partation 数量发生变化，那就很难保证 key 与分区之间的映射关系了。
3.自定义策略：实现 Partitioner 接口就能自定义分区策略。
4.指定 Partiton 发送
Kafka 支持读写分离吗？为什么？（了解）
Kafka 是不支持读写分离的，那么读写分离的好处是什么？主要就是让一个节点去承担另一个节点的负载压力，也就是能做到一定程度的负载均衡，而且 Kafka 不通过读写分离也可以一定程度上去实现负载均衡。
但是对于 Kafka 的架构来说，读写分离有两个很大的缺点
1.数据不一致的问题:读写分离必然涉及到数据的同步，只要是不同节点之间的数据同步，必然会有数据不一致的问题存在。
2.延时问题:由于 Kafka 独特的数据处理方式，导致如果将数据从一个节点同步到另一个节点必然会经过主节点磁盘和从节点磁盘，对一些延时性要求较高的应用来说，并不太适用
那 Kafka 是怎么去实现负载均衡的？（了解）
Kafka 的负责均衡主要是通过分区来实现的，我们知道 Kafka 是主写主读的架构，如下图:

共三个 broker ，里面各有三个副本，总共有三个 partation， 深色的是 leader，浅色的是 follower，上下灰色分别代表生产者和消费者，虚线代表 follower 从 leader 拉取消息。
我们从这张图就可以很明显的看出来，每个 broker 都有消费者拉取消息，每个 broker 也都有生产者发送消息，每个 broker 上的读写负载都是一样的，这也说明了 kafka 独特的架构方式可以通过主写主读来实现负载均衡。
Kafka 的可靠性是怎么保证的？

1.acks：这个参数用来指定分区中有多少个副本收到这条消息，生产者才认为这条消息是写入成功的，这个参数有三个值：
1.acks = 1，默认为1。生产者发送消息，只要 leader 副本成功写入消息，就代表成功。这种方案的问题在于，当返回成功后，如果 leader 副本和 follower 副本还没有来得及同步，leader 就崩溃了，那么在选举后新的 leader 就没有这条消息，也就丢失了。
2.acks = 0。生产者发送消息后直接算写入成功，不需要等待响应。这个方案的问题很明显，只要服务端写消息时出现任何问题，都会导致消息丢失。
3.acks = -1 或 acks = all。生产者发送消息后，需要等待 ISR 中的所有副本都成功写入消息后才能收到服务端的响应。毫无疑问这种方案的可靠性是最高的，但是如果 ISR 中只有leader 副本，那么就和 acks = 1 毫无差别了。
2.消息发送的方式：我们可以通过同步或者异步获取响应结果，失败做重试来保证消息的可靠性。
3.手动提交位移：默认情况下，当消费者消费到消息后，就会自动提交位移。但是如果消费者消费出错，没有进入真正的业务处理，那么就可能会导致这条消息消费失败，从而丢失。我们可以开启手动提交位移，等待业务正常处理完成后，再提交offset。
分区数越多越好吗？吞吐量就会越高吗？（了解）
在一定条件下，分区数的数量是和吞吐量成正比的，分区数和性能也是成正比的。
客户端/服务器端需要使用的内存就越多（超过了一定限度，就会对性能造成影响）
服务端在很多组件中都维护了分区级别的缓存，分区数越大，缓存成本也就越大。
消费端的消费线程数是和分区数挂钩的，分区数越大消费线程数也就越多，线程的开销成本也就越大
生产者发送消息有缓存的概念，会为每个分区缓存消息，当积累到一定程度或者时间时会将消息发送到分区，分区越多，这部分的缓存也就越大
什么情况下 kafka 会丢失消息？
Kafka 有三次消息传递的过程：生产者发消息给 Broker，Broker 同步消息和持久化消息，Broker 将消息传递给消费者。
1.生产者发送数据:
当 acks 为 0，只要服务端写消息时出现任何问题，都会导致消息丢失。
当 acks 配置为 1 时，生产者发送消息，只要 leader 副本成功写入消息，就代表成功。这种方案的问题在于，当返回成功后，如果 leader 副本和 follower 副本还没有来得及同步，leader 就崩溃了，那么在选举后新的 leader 就没有这条消息，也就丢失了。
2.Broker 存储数据:kafka 通过 Page Cache 将数据写入磁盘。
Page Cache 就是当往磁盘文件写入的时候，系统会先将数据流写入缓存中，但是什么时候将缓存的数据写入文件中是由操作系统自行决定。所以如果此时机器突然挂了，也是会丢失消息的。
3.消费者消费数据:在开启自动提交 offset 时，只要消费者消费到消息，那么就会自动提交偏移量，如果业务还没有来得及处理，那么消息就会丢失。

1、绝对路径用什么符号表示？当前目录、上层目录用什么表示？ 主目录用什么表示? 切换目录用什么命令？ （了解）
绝对路径： 如/etc/init.d
当前目录和上层目录： ./ ../
主目录： ~/
切换目录： cd
2、 怎么查看当前进程？怎么执行退出？怎么查看当前路径？
查看当前进程： ps
ps -l 列出与本次登录有关的进程信息； ps -aux 查询内存中进程信息； ps -aux | grep * 查询 进程的详细信息； top 查看内存中进程的动态信息； kill -9 pid 杀死进程。
执行退出： exit
查看当前路径： pwd
3、查看文件有哪些命令？
vi 文件名 #编辑方式查看，可修改
cat 文件名 #显示全部文件内容
more 文件名 #分页显示文件内容
less 文件名 #与 more 相似，更好的是可以往前翻页
tail 文件名 #仅查看尾部，还可以指定行数
head 文件名 #仅查看头部,还可以指定行数
4、列举几个常用的Linux命令
ls: 列出当前目录下的文件和子目录信息。
使用方式：ls [-options] [file/directory]
示例：ls /home/user 列出 /home/user 目录下的所有文件信息。
cd: 切换当前工作目录。
使用方式：cd [directory]
示例：cd Documents 切换到 Documents 目录，使用 cd … 返回上一级目录。
pwd: 显示当前工作目录的绝对路径。
使用方式：pwd
mkdir: 创建新的目录。
使用方式：mkdir [directory]
示例：mkdir javacn 创建 “javacn” 文件夹。
touch: 创建新文件或者更新已存在文件的时间戳。
使用方式：touch [file]
示例：touch newfile.txt
rm: 删除指定的文件或目录。
使用方式：rm [-options] file/directory
示例：rm file.txt（删除单个文件）、rm -r directory（递归删除目录及其内容）。
cp: 复制文件或目录。
使用方式：cp [-options] source destination
示例：cp file1.txt file2.txt（复制文件）、cp -r dir1 dir2（复制目录）
mv: 移动或重命名文件或目录。
使用方式：mv [-options] source destination
示例：mv file.txt newfile.txt（重命名文件）、mv file.txt /dir/（移动文件到指定目录）。
find: 在指定目录下查找满足条件的文件。
使用方式：find [path] [expression]
示例：find . -name “.txt” 在当前目录及其子目录下查找扩展名为 .txt 的文件。
grep: 搜索文件中匹配特定模式的行。
使用方式：grep [options] pattern file(s)
示例：grep “hello” file.txt 在 file.txt 中查找包含 “hello” 的行。
5、你平时是怎么查看日志的？
Linux查看日志的命令有多种: tail、cat、tac、head、echo等，本文只介绍几种常用的方法
1、tail
最常用的一种查看方式 命令格式: tail[必要参数][选择参数][文件]
-f 循环读取 -q 不显示处理信息 -v 显示详细的处理信息 -c＜数目＞ 显示的字节数 -n＜行数＞ 显示行数 - q, --quiet, --silent 从不输出给出文件名的首部 -s, --sleep-interval=S 与-f合用,表示在每次反复的间隔休眠S秒
例如：
tail -n 10 test.log 查询日志尾部最后10行的日志;
tail -n +10 test.log 查询10行之后的所有日志;
tail -fn 10 test.log 循环实时查看最后1000行记录(最常用的)

一般还会配合着grep搜索用，例如 :
tail -fn 1000 test.log | grep '关键字'
如果一次性查询的数据量太大,可以进行翻页查看，例如:
tail -n 4700 aa.log |more -1000 可以进行多屏显示(ctrl + f 或者 空格键可以快捷键)2、head
跟tail是相反的head是看前多少行日志
head -n 10 test.log 查询日志文件中的头10行日志;
head -n -10 test.log 查询日志文件除了最后10行的其他所有日志;

head其他参数参考tail3、cat
cat 是由第一行到最后一行连续显示在屏幕上
一次显示整个文件 :
$ cat filename
从键盘创建一个文件 :
$cat ＞ filename
将几个文件合并为一个文件：
$cat file1 file2 ＞ file 只能创建新文件,不能编辑已有文件
将一个日志文件的内容追加到另外一个 :
$cat -n textfile1 ＞ textfile2
清空一个日志文件:
$cat : ＞textfile2
注意：＞ 意思是创建，＞＞是追加。千万不要弄混了。
cat其他参数参考tail4、more
more命令是一个基于vi编辑器文本过滤器，它以全屏幕的方式按页显示文本文件的内容，支持vi中的关键字定位操作。more名单中内置了若干快捷键，常用的有H（获得帮助信息），Enter（向下翻滚一行），空格（向下滚动一屏），Q（退出命令）。more命令从前向后读取文件，因此在启动时就加载整个文件。
该命令一次显示一屏文本，满屏后停下来，并且在屏幕的底部出现一个提示信息，给出至今己显示的该文件的百分比：–More–（XX%）
more的语法：more 文件名
Enter 向下n行，需要定义，默认为1行
Ctrl f 向下滚动一屏
空格键 向下滚动一屏
Ctrl b 返回上一屏
= 输出当前行的行号
:f 输出文件名和当前行的行号
v 调用vi编辑器
!命令 调用Shell，并执行命令
q退出more5、sed
这个命令可以查找日志文件特定的一段 , 根据时间的一个范围查询，可以按照行号和时间范围查询
按照行号
sed -n '5,10p' filename 这样你就可以只查看文件的第5行到第10行。
按照时间段
sed -n '/2014-12-17 16:17:20/,/2014-12-17 16:17:36/p' test.log6、less
less命令在查询日志时，一般流程是这样的
less log.log
shift + G 命令到文件尾部 然后输入 ？加上你要搜索的关键字例如 ？1213
按 n 向上查找关键字
shift+n 反向查找关键字
less与more类似，使用less可以随意浏览文件，而more仅能向前移动，不能向后移动，而且 less 在查
看之前不会加载整个文件。
less log2013.log 查看文件
ps -ef | less ps查看进程信息并通过less分页显示
history | less 查看命令历史使用记录并通过less分页显示
less log2013.log log2014.log 浏览多个文件常用命令参数：
看之前不会加载整个文件。
less log2013.log 查看文件
ps -ef | less ps查看进程信息并通过less分页显示
history | less 查看命令历史使用记录并通过less分页显示
less log2013.log log2014.log 浏览多个文件
常用命令参数：
-b ＜缓冲区大小＞ 设置缓冲区的大小
-g 只标志最后搜索的关键词
-i 忽略搜索时的大小写
-m 显示类似more命令的百分比
-N 显示每行的行号
-o ＜文件名＞ 将less 输出的内容在指定文件中保存起来
-Q 不使用警告音
-s 显示连续空行为一行
/字符串：向下搜索"字符串"的功能
?字符串：向上搜索"字符串"的功能
n：重复前一个搜索（与 / 或 ? 有关）
N：反向重复前一个搜索（与 / 或 ? 有关）
b 向后翻一页
h 显示帮助界面
q 退出less 命令一般本人查日志配合应用的其他命令
history // 所有的历史记录
history | grep XXX // 历史记录中包含某些指令的记录
history | more // 分页查看记录
history -c // 清空所有的历史记录
!! 重复执行上一个命令
查询出来记录后选中 : !3236、Linux上如何查询某个端口是否被占用？
使用netstat命令：
netstat -tuln | grep ＜端口号＞这个命令会列出当前正在运行的所有TCP和UDP端口，并过滤出指定端口是否被占用。如果端口被占用，会显示对应的PID和程序名称。
使用ps命令结合grep命令：
ps -aux | grep ＜端口号＞这个命令会列出所有正在运行的进程，并过滤出包含指定端口号的进程信息。通过查看对应的PID和程序名称，可以判断该端口是否被占用。
7、实际工作中如何排查CPU飙升问题？
使用系统监控工具：首先，我们可以使用系统监控工具，如top命令，来查看所有进程占系统CPU的排序。这样可以帮助我们快速定位到占用CPU资源最多的进程
查看具体进程的CPU占用情况：接着，我们可以执行top -Hp 进程号命令，查看该进程下的所有线程占CPU的情况
查看耗CPU的线程：然后，我们可以执行printf "%x\n 线程号"命令，把线程号转成16进制，以便在后续查看线程堆栈信息
查看线程堆栈信息：我们可以执行jstack 进程号 | grep 线程ID命令，查找某进程下线程ID（jstack堆栈信息中的nid）的线程状态
查看GC情况：我们还可以执行jstat -gcutil 进程号 统计间隔毫秒 统计次数命令，查看某进程GC持续变化情况
查看进程的堆内存情况：我们可以执行jmap -heap 进程ID命令，查看一下进程的堆内从是不是要溢出了
导出内存heap到文件中：最后，我们可以执行jmap -dump:format=b,file=filename 进程ID命令，导出某进程下内存heap输出到文件中
8、场景题：项目本地能运行，发布到Linux后运行不了，可能是什么原因？该如何解决？
环境差异：本地环境和服务器环境可能存在差异，例如Java版本、系统环境变量、依赖库等。解决方法是确保服务器环境和本地环境尽可能一致
权限问题：可能是Linux服务器上的文件权限或者防火墙设置导致的。解决方法是检查并修改相关的权限设置
依赖问题：可能是项目依赖的库在服务器上不存在或版本不匹配。解决方法是检查项目的依赖，并确保它们在服务器上正确地被安装和配置
配置问题：可能是配置文件中的路径、数据库连接信息等在服务器上不适用。解决方法是检查并修改配置文件，确保它们在服务器环境中是正确的
8、什么是零拷贝技术？它有哪些使用场景？
零拷贝技术是一种优化数据传输的方法，它通过最小化数据在内存中的拷贝次数来提高数据传输的效率和性能。通常，在数据传输过程中，数据需要从一个缓冲区（如内核缓冲区）拷贝到另一个缓冲区（如用户空间缓冲区），然后再传输到目标位置。而零拷贝技术的目标是尽可能减少或消除这些拷贝操作，从而降低系统开销和提高性能。零拷贝技术的使用场景包括但不限于以下几种：
网络数据传输：在网络传输过程中，零拷贝技术可以避免数据在内核空间和用户空间之间的拷贝，从而提高网络数据传输的效率。常见的应用包括高性能网络服务器、网络流媒体服务等
文件传输：在文件传输过程中，零拷贝技术可以减少数据在文件系统缓存和用户空间缓冲区之间的拷贝次数，提高文件传输的效率。例如，在文件系统中实现零拷贝的技术可以加速文件的读取和写入操作
内存映射文件：内存映射文件是一种将文件映射到进程地址空间的技术，可以让应用程序直接操作文件而无需进行显式的读写操作。零拷贝技术可以用于内存映射文件的实现，从而提高文件的访问速度和效率
数据库系统：在数据库系统中，零拷贝技术可以用于加速数据的读取和写入操作，提高数据库的性能和吞吐量。例如，通过将数据库缓存直接映射到内存中，可以避免数据在内存和数据库之间的拷贝操作
9、Linux 调度程序是根据进程的动态优先级还是静态优先级来调度进程的?（了解）
Liunx 调度程序是根据根据进程的动态优先级来调度进程的,但是动态优先级又是根据静态 优先级根据算法计算出来的,两者是两个相关联的值。因为高优先级的进程总是比低优先级的进程先被调度,为防止多个高优先级的进程占用 CPU 资源,导致其他进程不能占有 CPU, 所以引用动态优先级概念

Maven&Git(了解)
1、Maven 是什么？
Maven 主要服务于基于 Java 平台的项目构建、依赖管理和项目信息管理。
Maven 的主要功能主要分为 5 点：
依赖管理系统
多模块构建
一致的项目结构
一致的构建模型和插件机制
2、Maven 常用命令
mvn archetype：create ：创建 Maven 项目。
mvn compile ：编译源代码。
mvn deploy ：发布项目。
mvn test-compile ：编译测试源代码。
mvn test ：运行应用程序中的单元测试。
mvn site ：生成项目相关信息的网站。
mvn clean ：清除项目目录中的生成结果。
mvn package ：根据项目生成的 jar/war 等。
mvn install ：在本地 Repository 中安装 jar 。
mvn eclipse:eclipse ：生成 Eclipse 项目文件。
mvn jetty:run 启动 Jetty 服务。
mvn tomcat:run ：启动 Tomcat 服务。
mvn clean package -Dmaven.test.skip=true ：清除以前的包后重新打包，跳过测试类。用到最多的命令
mvn eclipse:clean ：清除 Project 中以前的编译的东西，重新再来。
mvn eclipse:eclipse ：开始编译 Maven 的 Project 。
mvn clean package ：清除以前的包后重新打包。
3、Maven能解决什么问题？为什么要用？
在没有使用Maven的情况下，开发应用时需手动确定引入哪些第三方JAR包，然后去查找这些JAR包并将它们手动导入到项目中。同时，处理各个JAR包之间的兼容性和冲突问题是一项繁琐的任务。
完成JAR包的配置后，想要将应用打包成WAR包同样需要进行复杂的操作。整个应用的编译、测试和部署流程都显得特别繁杂。
然而，引入Maven后，这些问题迎刃而解。Maven是专为Java项目设计的管理和构建工具，其主要功能包括：
提供了一套依赖管理机制，简化了JAR包的引入和解决冲突的过程。
提供了标准化的构建流程，包括编译、测试、打包、发布等步骤。
定义了一套标准化的项目结构，使得项目组织更加清晰有序。
4、依赖的解析机制是什么呢？
当依赖的范围是 system 的时候，Maven 直接从本地文件系统中解析构件。
根据依赖坐标计算仓库路径，尝试直接从本地仓库寻找构件，如果发现对应的构件，就解析成功。
如果在本地仓库不存在相应的构件，就遍历所有的远程仓库，发现后，下载并解析使用。
如果依赖的版本是 RELEASE 或 LATEST，就基于更新策略读取所有远程仓库的元数据文件（groupId/artifactId/maven-metadata.xml），将其与本地仓库的对应元合并后，计算出 RELEASE 或者 LATEST 真实的值，然后基于该值检查本地仓库，或者从远程仓库下载。
如果依赖的版本是 SNAPSHOT，就基于更新策略读取所有远程仓库的元数据文件，将它与本地仓库对应的元数据合并，得到最新快照版本的值，然后根据该值检查本地仓库，或从远程仓库下载。
如果最后解析得到的构件版本包含有时间戳，先将该文件下载下来，再将文件名中时间戳信息删除，剩下 SNAPSHOT 并使用（以非时间戳的形式使用）。
5、jar包和war包有什么区别？
JAR包（Java Archive）和WAR包（Web Application Archive）都是Java中用于打包和部署应用程序的归档文件，但它们有不同的用途和特点：
1.JAR包（Java Archive）：
用途： 主要用于打包Java类、资源文件和库，通常用于独立的Java应用程序或Java库的发布。
结构： JAR包可以包含Java类、资源文件、配置文件和其他依赖的库（JAR文件）。
执行方式： JAR包通常以可执行的形式运行，其中包含一个MANIFEST.MF文件，指定了可执行类。
部署： JAR包可以通过java -jar命令执行，也可以作为库被其他Java项目引用。
2. WAR包（Web Application Archive）：
用途： 用于打包和部署Web应用程序，包含Web应用所需的所有资源，例如Servlet、JSP、HTML、CSS、JavaScript等。
结构： WAR包包含Web应用的目录结构，通常包括WEB-INF目录、WEB-INF/lib目录（用于存放依赖的JAR文件）和WEB-INF/classes目录（用于存放编译后的Java类）。
执行方式： WAR包通常被部署在支持Servlet规范的Web容器（如Tomcat、Jetty）中，并由容器负责执行。
部署： WAR包通过将其复制到Web容器的指定目录进行部署，容器会自动解压并运行其中的Web应用。
总结：
JAR包主要用于打包和部署独立的Java应用程序或库。
WAR包主要用于打包和部署Web应用程序，包括Web应用所需的所有资源。
JAR包通常以可执行的形式运行，而WAR包被部署在Web容器中执行。
6、如何解决Git冲突？
1、git冲突的场景
情景一：多个分支代码合并到一个分支时；
情景二：多个分支向同一个远端分支推送代码时；
实际上，push操作即是将本地代码merge到远端库分支上。
关于push和pull其实就分别是用本地分支合并到远程分支 和 将远程分支合并到本地分支
所以这两个过程中也可能存在冲突。
git的合并中产生冲突的具体情况：
两个分支中修改了同一个文件（不管什么地方）
两个分支中修改了同一个文件的名称
两个分支中分别修改了不同文件中的部分，不会产生冲突，可以直接将两部分合并。
2、冲突解决方法
情景一：在当前分支上，直接修改冲突代码

1、什么是Mybatis（了解）
Mybatis 是一个半ORM框架，它内部封装了 JDBC，开发时只需要关注 SQL 语句本身，不需要花费精力去处理加载驱动、创建连接、创建statement 等繁杂的过程。程序员直接编写原生态 sql，可以严格控制 sql 执行性能，灵活度高。MyBatis 可以使用 XML 或注解来配置和映射原生信息，将 POJO 映射成数据库中的记录，避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。通过 xml 文件或注解的方式将要执行的各种 statement 配置起来，并通过java 对象和 statement 中 sql 的动态参数进行映射生成最终执行的 sql 语句，最后由 mybatis 框架执行 sql 并将结果映射为 java 对象并返回。
2、#{}和${}的区别是什么？
预编译与字符串替换：
#{}：表示一个预编译的SQL参数占位符。当使用#{}时，MyBatis会将参数值嵌入到SQL语句的预编译部分中，并使用JDBC的PreparedStatement对象来设置参数值。这种方式可以防止SQL注入，因为它确保用户输入被当作参数值而不是SQL的一部分来处理。
${}：表示一个字符串替换占位符。当使用${}时，MyBatis会直接将参数值替换到SQL语句中，而不是作为参数值来处理。这意味着用户输入的内容将被直接插入到SQL语句中，因此存在SQL注入的风险。
数据类型处理：
#{}：MyBatis会处理参数的数据类型，并确保参数值被正确地传递给JDBC的PreparedStatement对象。如果参数是null，MyBatis会将其转换为JDBC的NULL值。
${}：MyBatis不会处理参数的数据类型。你需要确保替换的字符串是有效的SQL片段，并且如果参数是null，则需要在SQL语句中显式处理它。
3、当实体类中的属性名和表中的字段名不一样 ，怎么办 ？
第1种： 通过在查询的sql语句中定义字段名的别名，让字段名的别名和实体类的属性名一致。
＜select id=”selectorder” parametertype=”int” resultetype=”me.gacl.domain.order”＞
select order_id id, order_no orderno ,order_price price form orders where
order_id=#{id};
＜/select＞第2种： 通过来映射字段名和实体类属性名的一一对应的关系。
＜select id="getOrder" parameterType="int" resultMap="orderresultmap"＞
select * from orders where order_id=#{id}
＜/select＞
＜resultMap type=”me.gacl.domain.order” id=”orderresultmap”＞
＜!–用id属性来映射主键字段–＞
＜id property=”id” column=”order_id”＞
＜!–用result属性来映射非主键字段，property为实体类属性名，column为数据表中的属性–＞
＜result property = “orderno” column =”order_no”/＞
＜result property=”price” column=”order_price” /＞
＜/reslutMap＞4、Mybatis是否支持延迟加载？如果支持，它的实现原理是什么？
Mybatis仅支持association关联对象和collection关联集合对象的延迟加载，association指的就是一对一，collection指的就是一对多查询。在Mybatis配置文件中，可以配置是否启用延迟加载lazyLoadingEnabled=true|false。
它的原理是，使用CGLIB创建目标对象的代理对象，当调用目标方法时，进入拦截器方法，比如调用a.getB().getName()，拦截器invoke()方法发现a.getB()是null值，那么就会单独发送事先保存好的查询关联B对象的sql，把B查询上来，然后调用a.setB(b)，于是a的对象b属性就有值了，接着完成a.getB().getName()方法的调用。这就是延迟加载的基本原理。
当然了，不光是Mybatis，几乎所有的包括Hibernate，支持延迟加载的原理都是一样的。
5、说说Mybatis的缓存机制:
Mybatis整体：

一级缓存localCache
在应用运行过程中，我们有可能在一次数据库会话中，执行多次查询条件完全相同的 SQL，MyBatis 提供了一级缓存的方案优化这部分场景，如果是相同的 SQL 语句，会优先命中一级缓存，避免直接对数据库进行查询，提高性能。
每个 SqlSession 中持有了 Executor，每个 Executor 中有一个 LocalCache。当用户发起查询时，MyBatis 根据当前执行的语句生成 MappedStatement，在 Local Cache 进行查询，如果缓存命中的话，直接返回结果给用户，如果缓存没有命中的话，查询数据库，结果写入 Local Cache，最后返回结果给用户。具体实现类的类关系图如下图所示

MyBatis 一级缓存的生命周期和 SqlSession 一致。
MyBatis 一级缓存内部设计简单，只是一个没有容量限定的 HashMap，在缓存的功能性上有所欠缺。
MyBatis 的一级缓存最大范围是 SqlSession 内部，有多个 SqlSession 或者分布式的环境下，数据库写操作会引起脏数据，建议设定缓存级别为 Statement。
二级缓存
在上文中提到的一级缓存中，其最大的共享范围就是一个 SqlSession 内部，如果多个 SqlSession之间需要共享缓存，则需要使用到二级缓存。开启二级缓存后，会使用 CachingExecutor 装饰Executor，进入一级缓存的查询流程前，先在 CachingExecutor 进行二级缓存的查询，具体的工作流程如下所示。

二级缓存开启后，同一个 namespace 下的所有操作语句，都影响着同一个 Cache，即二级缓存被多个 SqlSession 共享，是一个全局的变量。
当开启缓存后，数据的查询执行的流程为：
二级缓存 -＞ 一级缓存 -＞ 数据库
MyBatis 的二级缓存相对于一级缓存来说，实现了 SqlSession 之间缓存数据的共享，同时粒度更加细，能够到 namespace 级别，通过 Cache 接口实现类不同的组合，对 Cache 的可控性也更强。
MyBatis 在多表查询时，极大可能会出现脏数据，有设计上的缺陷，安全使用二级缓存的条件比较苛刻。
在分布式环境下，由于默认的 MyBatis Cache 实现都是基于本地的，分布式环境下必然会出现读取到脏数据，需要使用集中式缓存将 MyBatis 的 Cache 接口实现，有一定的开发成本，直接使用 Redis、Memcached 等分布式缓存可能成本更低，安全性也更高。

1、一个查询语句是怎么执行的？

连接器负责验证用户身份，包括账户密码和权限检查。成功登录后，连接器获取用户权限信息，后续的权限验证都基于这一次获取的权限数据。即使管理员在连接未断开的情况下修改用户权限，用户仍不受影响。
查询缓存在连接建立后起作用，先检查是否有相同的查询语句在缓存中，如果有，则直接返回缓存结果。新的查询结果也会被缓存，但在执行缓存查询时仍会校验用户权限。尽管在 MySQL 8.0 版本后删除了查询缓存功能，这是因为该功能对于频繁更新的数据效果不佳，对于不经常更新的数据才更为适用。
分析器包括词法分析和语法分析。首先，词法分析提取关键字、表名、字段名和查询条件等信息。然后，语法分析检查 SQL 语句是否符合 MySQL 的语法规则。这两步完成后，进入执行阶段，但为了达到最佳执行效果，需要优化器的介入。
优化器的任务是选择认为最优的执行方案，例如在多个索引中选择合适的索引、确定多表查询的关联顺序等。其目标是为了执行器提供一个最优的执行计划，尽管有时候可能并非绝对最优。
执行器执行前会校验用户权限，若无权限则返回错误信息，有权限则调用存储引擎的接口执行 SQL 语句，返回执行结果。整个流程保证了安全性和性能的平衡。
2、Innodb和MyIsam的区别？
InnoDB支持事务处理和外键，具有提交、回滚和崩溃恢复能力来保护用户数据。而MyISAM不支持事务处理等高级处理。
InnoDB支持行级锁定（默认），而MyISAM只支持表级锁定。
InnoDB采用的是聚簇索引的方式，索引和数据紧密结合；而MyISAM则是索引与数据分开存储。
InnoDB支持外键，而MyISAM不支持。
InnoDB是聚集索引，数据文件本身就是索引文件；而MyISAM是非聚集索引，索引文件和数据文件是分开的。
3、关系型数据库和非关系型数据库的区别是什么？（了解）
关系型数据库（如MySQL）使用关系模型来组织数据，支持复杂查询，保持数据一致性，并且数据更新的开销较小。
非关系型数据库（如NoSQL）无需经过SQL层的解析，读写效率高，基于键值对，易于扩展，并支持多种类型数据的存储。
4、MySQL的索引是什么？为什么使用索引？
索引是数据库对象，可以提高数据检索的速度。
使用索引的根本原因是为了提高数据查询的效率，就像书的目录一样。对于数据库的表而言，索引其实就是它的“目录”。索引还可以帮助引擎层避免排序和临时表，将随机IO变为顺序IO，加速表和表之间的连接。
5、MySQL的三大范式是什么？（了解）
第一范式（1NF）：属性不可分割，即每个属性都是不可分割的原子项。
第二范式（2NF）：满足第一范式，且不存在部分依赖，即非主属性必须完全依赖于主属性。
第三范式（3NF）：满足第二范式，且不存在传递依赖，即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性，不能间接依赖主属性。

6、如何优化MySQL查询？
使用索引：
确保在经常用于搜索、排序和连接的列上创建索引。
使用EXPLAIN来检查查询是否正在使用索引，以及索引是否被有效地使用。
对于COUNT(*)操作，如果不需要精确计数，可以考虑使用近似值或估算值。
避免SELECT *：
只选择需要的列，而不是使用SELECT *来选择所有列。这可以减少数据传输的开销，并可能提高查询速度。
使用连接（JOIN）代替子查询：
当可能时，使用JOIN代替子查询，因为JOIN操作通常比子查询更高效。
优化GROUP BY 和 ORDER BY：
尽量在具有索引的列上使用GROUP BY和ORDER BY。
对于GROUP BY，如果可能的话，在子查询中先过滤数据，然后再进行分组。
优化数据类型和表结构：
使用合适的数据类型来存储数据，例如，使用INT代替VARCHAR来存储整数。
规范化数据库设计以减少数据冗余并提高数据一致性。
使用分区表来管理大表，提高查询性能。
避免使用LIKE '%value%'：
这种模糊查询模式会导致全表扫描，非常耗时。如果可能的话，尽量避免使用它，或者使用更具体的查询条件。
符合最左匹配原则
7、什么是数据库事务？
数据库事务（Database Transaction）是指作为单个逻辑工作单元执行的一系列操作。这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。事务由事务开始（Begin Transaction）和事务结束（End Transaction）之间执行的全体数据库操作组成。
事务具有四个标准属性，通常简称为ACID属性：
原子性（Atomicity）：事务是一个原子操作单元，其对数据的修改要么全都执行，要么全都不执行。
一致性（Consistency）：在事务开始和完成时，数据库都必须处于一致性状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
隔离性（Isolation）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读-未提交（Read Uncommitted）、读-已提交（Read Committed）、可重复读（Repeatable Read）和串行化（Serializable）。
持久性（Durability）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
8、mysql聚簇和非聚簇索引的区别

聚簇索引：将数据存储与索引放到了一块、并且是按照一定的顺序组织的，找到索引也就找到了数据，数据的物理存放顺序与索引顺序是一致的，即：只要索引是相邻的，那么对应的数据一定也是相邻地存放在磁盘上的
非聚簇索引：叶子节点不存储数据、存储的是数据行地址，也就是说根据索引查找到数据行的位置再取磁盘查找数据，这个就有点类似一本树的目录，比如我们要找第三章第一节，那我们先在这个目录里面找，找到对应的页码后再去对应的页码看文章。
优势：
1、查询通过聚簇索引可以直接获取数据，相比非聚簇索引需要第二次查询（非覆盖索引的情况下）效率
要高
2、聚簇索引对于范围查询的效率很高，因为其数据是按照大小排列的
3、聚簇索引适合用在排序的场合，非聚簇索引不适合
劣势：
1、维护索引很昂贵，特别是插入新行或者主键被更新导至要分页(page split)的时候。建议在大量插
入新行后，选在负载较低的时间段，通过OPTIMIZE TABLE优化表，因为必须被移动的行数据可能造成
碎片。使用独享表空间可以弱化碎片
2、表因为使用UUId（随机ID）作为主键，使数据存储稀疏，这就会出现聚簇索引有可能有比全表扫面
更慢，所以建议使用int的auto_increment作为主键
3、如果主键比较大的话，那辅助索引将会变的更大，因为辅助索引的叶子存储的是主键值；过长的主键
值，会导致非叶子节点占用占用更多的物理空间
9、B+树索引的数据结构?
B+树索引的数据结构是一种在数据库中常用的索引结构，用于提高检索效率。它的特点使其在磁盘存储和检索方面表现出色。以下是B+树索引的基本数据结构：
定义：B+树是一种平衡树，它在树的每个非叶子节点上保存了一定数量的键值，并且这些键值用于确定下一步搜索的方向。B+树的特点是具有多路搜索的能力。
节点结构：
内部节点：包含一组有序的键值，每个键值对应着树的一个分支，用于指向子树。内部节点不存储实际的数据，只用于导航。
叶子节点：包含键值和对应的数据的引用（即指针指向实际的数据块）。B+树只能叶子节点的指针指向主文件，而B树的每个节点都存放指向主文件的指针。此外，叶子节点之间通过指针相连，从而可以方便地进行范围查找。
在B+树中，数据按照主键值的大小顺序进行排序，每个数据页中的记录会按照主键值从小到大的顺序组成一个单向链表，而各个数据页之间则通过双向链表进行连接。这种结构使得B+树在查找、排序和范围查找等操作中都具有较高的效率。

10、索引设计的原则？
查询更快、占用空间更小
适合索引的列是出现在where子句中的列，或者连接子句中指定的列
基数较小的表，索引效果较差，没有必要在此列建立索引
使用短索引，如果对长字符串列进行索引，应该指定一个前缀长度，这样能够节省大量索引空间，如果搜索词超过索引前缀长度，则使用索引排除不匹配的行，然后检查其余行是否可能匹配。
不要过度索引。索引需要额外的磁盘空间，并降低写操作的性能。在修改表内容的时候，索引会进行更新甚至重构，索引列越多，这个时间就会越长。所以只保持需要的索引有利于查询即可。
定义有外键的数据列一定要建立索引。
更新频繁字段不适合创建索引
若是不能有效区分数据的列不适合做索引列(如性别，男女未知，最多也就三种，区分度实在太低)8. 尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。
对于那些查询中很少涉及的列，重复值比较多的列不要建立索引。
对于定义为text、image和bit的数据类型的列不要建立索引
11、什么是脏读、幻读、不可重复读？
在数据库管理系统中，脏读（Dirty Read）、幻读（Phantom Read）和不可重复读（Non-repeatable Read）是事务并发执行时可能遇到的问题，它们都属于事务的隔离性（Isolation）问题。
脏读（Dirty Read）：
定义：一个事务读取了另一个尚未提交的事务的修改数据。
示例：事务A修改了一个数据项的值，但还没有提交这个修改，此时事务B读取了这个被修改后的数据项。如果事务A最终发生错误并执行了回滚操作，那么事务B读取到的数据就是“脏数据”。
解决方法：通过增强事务的隔离级别来避免脏读，例如使用READ COMMITTED或更高的隔离级别。
不可重复读（Non-repeatable Read）：
定义：在同一个事务内，多次读取同一数据返回的结果有所不同。这通常是因为另一个并发事务对数据进行了修改并提交。
示例：事务A在读取某个数据项的值后，事务B修改了这个数据项并提交，然后事务A再次读取这个数据项时，发现它的值已经改变。
解决方法：同样可以通过增强事务的隔离级别来避免不可重复读，但通常需要使用比READ COMMITTED更高的隔离级别，如REPEATABLE READ或SERIALIZABLE。
幻读（Phantom Read）：
定义：当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还存在没有修改的数据行，就好象发生了幻觉一样。
示例：事务A按照某个条件读取了一个数据集合，然后事务B插入了一个满足这个条件的新数据并提交，接着事务A再次按照同样的条件读取数据，发现多了一行数据。
解决方法：使用更严格的隔离级别，如SERIALIZABLE，或者使用特定的锁策略来避免幻读。在某些数据库系统中，如InnoDB，即使使用了REPEATABLE READ隔离级别，也会通过多版本并发控制（MVCC）等技术来避免幻读。
12、事务的隔离级别

读未提交（Read Uncommitted）：
这是最低的隔离级别，事务中的未提交修改对其他事务可见。
存在脏读（Dirty Read）问题，即一个事务可能读取到另一个未提交事务的数据。
适用于对数据一致性要求较低、并发性能要求较高的场景。
读已提交（Read Committed）：
事务只能读取到其他事务已提交的数据，避免脏读问题。
读取操作不会阻塞其他事务的修改，读取到的始终是最新已提交的数据。
解决了脏读问题，但仍可能出现不可重复读和幻读现象。
适用于需要避免脏读、对一致性要求适中、追求较高并发性能的场景。
可重复读（Repeatable Read）（MySQL的默认隔离级别）：
保证在同一事务中多次读取同一数据时，结果始终一致。
当前事务提交前，其他事务无法修改该事务读取的数据，避免了不可重复读问题。
仍可能存在幻读问题，即同一查询在不同时间可能返回不同的结果集。
适用于对数据一致性要求高、并发性能要求一般的场景。
串行化（Serializable）：
这是最高的隔离级别，确保事务之间的完全隔离。
事务在读取和修改数据时，数据会被锁定，其他事务不能对其进行操作。
解决了脏读、不可重复读和幻读问题，但牺牲了执行效率。
适用于对数据一致性要求极高、且并发性能要求较低的场景。
13、MySQL 的默认的隔离级别？
MySQL 的默认隔离级别是 可重复读（Repeatable Read）。这意味着，在同一个事务中，多次读取同样的数据结果都是一致的。即使其他事务在此期间对数据进行了修改并提交，该事务仍然只能看到它开始时看到的数据行。
这种隔离级别基于多版本并发控制（Multi-Version Concurrency Control, MVCC）实现，使得读操作和写操作（在一定程度上）可以并发执行，从而提高了系统的并发性能。
14、如何理解MVCC？（了解）
MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种并发控制的方法，主要在数据库管理系统中实现对数据库的并发访问，并在编程语言中实现事务内存。其核心思想是通过保存数据在某个时间点上的快照来允许多个事务同时读取数据，而不会相互干扰，从而提高了数据库的并发性能。
以下是MVCC的主要特点和工作原理：
版本管理：MVCC通过在系统中维护多个版本的数据来实现对并发事务的支持。每个事务在开始时都会获得一个唯一的ID，当事务要访问某个数据时，系统会检查该数据的版本是否与事务的ID相匹配。
读写隔离：通过使用版本号或时间戳来标记每个事务的读写版本，MVCC将读操作与写操作进行隔离，避免了读写冲突。当一个事务正在读取某个数据时，其他事务可以继续并发地进行读操作或写操作（写入新数据版本），而不会相互阻塞。
数据快照：MVCC会保存某个时间点上的数据快照。这意味着事务可以看到一个一致的数据视图，无论它们需要运行多长时间。同时，这也意味着不同的事务在同一个时间点看到的同一个表的数据可能是不同的。
实现方式：各个数据库系统对MVCC的实现方式可能有所不同。以MySQL的InnoDB存储引擎为例，它通过为每一行记录添加两个额外的隐藏的值来实现MVCC，这两个值分别记录这行数据何时被创建和何时过期（或被删除）。InnoDB并不直接存储这些事件发生时的实际时间，而是使用了一个随着事务创建而不断增长的系统版本号。
使用场景：MVCC在多种场景下都非常有用，包括长事务场景、快照读取场景、分布式数据库场景和高可用性场景等。通过版本号或时间戳来标记每个事务的读写版本，MVCC可以实现数据的多版本存储，从而提高了数据库的并发性能和响应速度。
15、InnoDB的各种锁？
行锁（Row Locks）：
InnoDB存储引擎实现了行级锁定，这是其与其他存储引擎（如MyISAM）的主要区别之一。行锁允许数据库系统对某一行记录进行加锁，而不必锁定整张表，从而提高了并发性能。
当事务需要修改某行数据时，InnoDB会对其加上行锁，以确保在事务完成之前其他事务不能修改该行数据。
表锁（Table Locks）：
尽管InnoDB主要使用行锁，但在某些情况下，如没有使用索引的查询或某些系统操作，InnoDB可能会使用表锁。
表锁会锁定整张表，阻止其他事务对表中的任何数据进行读写操作。
共享锁（Shared Locks，S锁）：
也称为读锁，允许多个事务同时读取同一资源，但阻止其他事务修改该资源。
当一个事务持有一个资源的共享锁时，其他事务可以对该资源加共享锁，但不能加排他锁。
排他锁（Exclusive Locks，X锁）：
又称为写锁，它允许事务修改数据并阻止其他事务同时获取相同资源的任何类型的锁。
在InnoDB引擎下，执行写操作（UPDATE、DELETE、INSERT）时会自动给涉及到的数据加上X锁。
意向锁（Intention Locks）：
是一种表明一个事务想要在行上设置共享锁或排他锁的锁。它是一种多粒度锁定机制中的一部分，用于解决行锁和表锁之间的冲突。
意向锁是InnoDB自动加的，不需用户干预。
记录锁（Record Locks）：
是单个行记录上的锁，它阻止其他事务修改或删除同一行。
间隙锁（Gap Locks）：
锁定一个范围，但不包括记录本身。间隙锁主要用于防止幻读，即当一个事务读取一个范围内的记录时，另一个事务在该范围内插入新的记录。
16、什么是buffer pool？
MySQL的数据通常存储在磁盘上（除了Memory引擎）。然而，为了提升读写性能，InnoDB引擎引入了一个关键的中间层，即缓冲池（buffer pool）。
缓冲池是一块连续的内存空间，主要用于缓存数据页。每个数据页的大小通常为16KB。引入缓冲池的目的是为了减少直接与磁盘的频繁交互，从而提高数据读写的性能。在这个缓冲池中，数据页可以被快速读取和写入，减少了对磁盘的访问次数，有效地提升了数据库的整体性能。
在引入buffer pool之后，当执行数据查询操作时，InnoDB首先会检查Buffer Pool中是否已经缓存了相应的数据。如果数据已存在于缓冲池中，查询就能直接从内存中获取，避免了频繁的磁盘读取，从而显著提高了查询性能。如果数据尚未在缓冲池中找到，系统会从磁盘中读取相应的数据。如果在磁盘中找到了数据，系统会将该数据所在的页直接复制到buffer pool中，并将查询结果返回给客户端。这样，对于后续的查询，可以直接从buffer pool中就近读取数据，进一步优化了查询性能。
在进行数据修改时，也遵循类似的过程，首先需要在buffer pool中进行修改，然后将修改后的数据写回到磁盘。
由于buffer pool是基于内存的，其空间是有限的，其默认大小为128M。然而，这个大小并非完全固定，可以通过调整MySQL配置文件中的innodb_buffer_pool_size参数来灵活地调整Buffer Pool的大小。
17、InnoDB的索引结构为什么是B+树?
在范围查询方面，B+树的设计使得范围查找变得简单高效。从根节点遍历至叶子节点即可，因为数据集中存储在叶子节点上，并通过叶子节点之间的指针连接，使范围查找操作得以轻松实现。
B+树为排序操作提供了快速支持。通过将关键字有序存储在叶子节点中，系统能够迅速执行排序操作，有效提高整体排序效率。
针对索引数据的存储，B+树通过将实际数据仅存储在叶子节点，而非叶子节点仅存储索引关键字的方式，实现了更多索引数据的存储，从而优化了系统的索引性能。
在节点分裂和合并操作中，B+树通过固定叶子节点大小并将节点大小设置为一页的大小，降低了IO操作的频率。这种设计有效减少了在节点分裂和合并时的IO负担，仅需读取和写入一页，提升了系统的整体效率。
利用B+树的节点大小固定特性，系统充分发挥磁盘预读特性，一次性读取多个节点到内存中。这种优化策略有效减少了IO操作次数，提高了查询效率。
B+树的缓存设计也为系统性能提供了优势。非叶子节点仅存储指向子节点的指针而不包含实际数据，从而提高了缓存容纳更多索引数据的能力，进而增加了缓存的命中率，显著提升了查询速度。
拓展知识：
MySql这样的关系型数据库在查询方面有一些重要特性，是KV型的数据库或者缓存所不具备的，比如：
范围查询。
前缀匹配模糊查询。
排序和分页
这些特性的支持，要归功于B+树这种数据结构。那么我们来分析一下B+树是如何支持这些特性的。
逻辑结构
这里我们拿数据库主键对应的B+树逻辑结构来说明，这个结构有几个关键特性：
在叶子节点一层，所有记录的主键按照从小到大的顺序排 列，并且形成了一个双向链表。叶子节点的每一个Key指向一条记录。
非叶子节点取的是叶子节点里面Key的最小值。这意味着所有 非叶子节点的Key都是冗余的叶子节点。同一层的非叶子节点也互相串联，形成了一个双向链表。
解释下什么是叶子节点什么是非叶子节点
叶子节点是指在数据库的存储和索引结构中，没有子节点的节点。在B树和B+树索引结构中，叶子节点是位于树的最底层的节点，它存储了实际的数据记录。叶子节点通常包含了关键字和指向实际数据记录的指针。
非叶子节点是指在数据库的存储和索引结构中，有子节点的节点。在B树和B+树索引结构中，非叶子节点用于存储索引信息，它们通常包含了关键字和指向子节点的指针。
下面的结构图可以更好的说明这两个特性：

基于这样一个数据结构以上特性就更好说明了：
范围查询：比如要查主键在[1,17]之间的记录。二次查询，先查找 1所在的叶子节点的记录位置，再查找17所在的叶子节点记录的位置 （就是16所处的位置），然后顺序地从1遍历链表直到16所在的位置。
前缀匹配模糊查询：假设主键是一个字符串类型，要查询where Key like abc%，其实可以转化成一个范围查询Key in [abc,abcz]。当然，如果是后缀匹配模糊查询，或者诸如where Key like %abc%这样的中间 匹配，则没有办法转化成范围查询，只能挨个遍历。
排序与分页：叶子节点天然是排序好的，支持排序和分页。
物理结构
上面的树只是一个逻辑结构，最终要存储到磁盘上。下面就以MySQL中最常用的InnoDB引擎为例，看一下如何实现B+树的存储。
对于磁盘来说，不可能一条条地读写，而都是以“块”为单位进行读 写的。InnoDB默认定义的块大小是16KB，通过innodb_page_size参数指定。这里所说的“块”，是一个逻辑单位，而不是指磁盘扇区的物理块。 块是InnoDB读写磁盘的基本单位，InnoDB每一次磁盘I/O，读取的都是 16KB的整数倍的数据。无论叶子节点，还是非叶子节点，都会装在 Page里。InnoDB为每个Page赋予一个全局的32位的编号，所以InnoDB 的存储容量的上限是64TB（2^30×16KB）。
16KB是一个什么概念呢？如果用来装非叶子节点，一个Page大概 可以装1000个Key（16K，假设Key是64位整数，8个字节，再加上各种其他字段），意味着B+树有1000个分叉；如果用来装叶子节点，一个 Page大概可以装200条记录（记录和索引放在一起存储，假设一条记录大概100个字节）。基于这种估算，一个三层的B+树可以存储多少数据 量呢？如图下图所示：

第一层：一个节点是一个Page，里面存放了1000个Key，对应1000 个分叉。
第二层：1000个节点，1000个Page，每个Page里面装1000个Key。
第三层：1000×1000个节点（Page），每个Page里面装200条记录， 即是1000×1000×200 =2亿条记录，总容量是16KB×1000×1000，约16GB。
把第一层和第二层的索引全装入内存里，即（1+1000）×16KB，也 即约16MB的内存。三层B+树就可以支撑2亿条记录，并且一次基于主 键的等值查询，只需要一次I/O（读取叶子节点）。由此可见B+树的强 大！
基于Page，最终整个B+树的物理存储类似下图所示：

Page与Page之间组成双向链表，每一个Page头部有两个关键字段： 前一个Page的编号，后一个 Page 的编号。Page 里面存储一条条的记 录，记录之间用单向链表串联，最终所有的记录形成上面所示的双向链表的逻辑结构。对于记录来说，定位到了Page，也就定位到了Page里面的记录。因为Page会一次性读入内存，同一个Page里面的记录可以在内存中顺序查找。
在InnoDB的实践里面
其中一个建议是按主键的自增顺序插入记 录，就是为了避免Page Split问题。比如一个Page里依次装入了Key为（1,3,5,9）四条记录，并且假设这个Page满了。接下来如果插入一个 Key =4的记录，就不得不建一个新的Page，同时把（1,3,5,9）分成两半，前一半（1,3,4）还在旧的Page中，后一半（5,9）拷贝到新的Page 里，并且要调整Page前后的双向链表的指针关系，这显然会影响插入速 度。但如果插入的是Key=10的记录，就不需要做Page Split，只需要建 一个新的Page，把Key = 10的记录放进去，然后让整个链表的最后一个 Page指向这个新的Page即可。
另外一个点，如果只是插入而不硬删除记录（只是软删除），也会避免某个Page的记录数减少进而发生相邻的Page合并的问题。
18、Innodb的RR有没有彻底解决幻读问题？（了解）
在InnoDB中，使用REPEATABLE READ隔离级别通过临键锁和MVCC（多版本并发控制）机制解决了许多幻读问题，但并非所有情况下都能完全消除幻读。为了彻底解决幻读，需要使用更严格的Serializable隔离级别。
在REPEATABLE READ中，通过引入临键锁解决了一些当前读操作可能导致的幻读问题。通过在记录之间增加间隙锁，阻止了新数据的插入，从而防止了某些幻读情况的发生。
此外，REPEATABLE READ中使用MVCC机制来解决快照读操作可能引起的幻读问题。在REPEATABLE READ中，快照读仅在第一次执行数据查询时实际获取数据快照，后续的快照读直接读取之前获取的快照，从而避免了快照读阶段的幻读。
然而，在一些特定场景下，即便是REPEATABLE READ，仍然存在幻读的可能性。例如，在两个事务中，事务1首先执行了快照读，然后事务2插入了一条记录并提交。接着，事务1进行了更新操作，成功地更新了事务2插入的记录，这就是一种幻读情况。另外，如果两个事务中，事务1进行了快照读，然后事务2插入了一条记录并提交，随后事务1进行了当前读，再进行快照读，同样会发生幻读。
19、什么是回表，怎么减少回表的次数？（了解）
在InnoDB中，索引采用B+树结构，其中主键索引被称为聚簇索引，其叶子节点直接存储了整行数据。相反，非主键索引，也称为非聚簇索引，其叶子节点存储的是主键的值。
在数据存储方面，通过主键（聚簇）索引进行查询时，B+树的叶子节点直接包含所需的整行数据。而在使用非主键（非聚簇）索引进行查询时，首先通过非聚簇索引获取主键的值，然后需要再次通过主键进行一次查询才能获取目标数据。这个两步查询的过程被称为回表。
因此，在InnoDB中，通过主键进行查询更为高效，因为这个过程无需进行回表操作。此外，借助覆盖索引、索引下推等技术，我们可以通过优化索引结构和SQL语句来降低回表的次数。
20、解释下什么是索引覆盖及索引下推？
索引覆盖（Index Covering）：
概念： 当一个查询的结果可以直接从索引中获取，而不需要访问实际的数据行时，就称为索引覆盖。
优势： 索引覆盖可以减少对实际数据的访问，提高查询效率，尤其在需要检索大量数据时更为显著。
实现： 通过创建包含所有需要查询的字段的索引，查询的结果可以完全通过索引来满足，而不必读取实际的数据行。
索引下推（Index Condition Pushdown）：
概念： 索引下推是指在查询过程中，将一部分过滤条件推送到存储引擎层，减少从存储引擎获取的数据量。这些过滤条件在索引层面进行处理，而不是在存储引擎获取数据后再进行过滤。
优势： 通过在索引层面进行条件过滤，可以减少需要检索和传输的数据量，提高查询性能。
实现： 当查询条件中的一部分可以在索引中进行评估时，数据库系统可以选择将这部分条件下推到索引层面执行，从而减少实际数据行的访问。
21、什么是最左前缀匹配？

在MySQL中，最左前缀匹配是一种利用索引的最左边部分进行查询匹配的机制。具体而言，当执行查询时，如果查询条件涉及到了组合索引的前几个列，MySQL可以利用这个复合索引进行匹配。
组合索引是指由多个字段组成的联合索引，例如，idx_col1_col2_col3 (col1, col2, col3)。
假设我们创建了一个组合索引 (col1, col2, col3)，那么当查询条件涉及 col1、(col1, col2)或者(col1, col2, col3) 时，MySQL可以使用这个复合索引进行最左前缀匹配。
然而，如果查询条件只涉及 col2 或者只涉及 col3，或者同时涉及 col2 和 col3 但不包含 col1，通常情况下（忽略其他优化如索引跳跃扫描等），就不能利用这个索引进行最左前缀匹配。
值得注意的是，最左前缀匹配与查询条件的列顺序无关。无论查询条件是 where col1 = "xxx" and col2 = "yyy" 还是 where col2 = "yyy" and col1 = "xxx"，结果都不受影响，仍然可以利用最左前缀匹配。
另外，需要澄清的是，创建一个组合索引 (col1, col2, col3) 并不会在数据库中创建三个独立的索引 (col1)、(col1, col2) 和 (col1, col2, col3)。实际上，它创建的是一棵B+树，按照 col1 的排序顺序，当 col1 相同时按照 col2 排序，col2 相同时再按照 col3 排序。
22、设计索引的时候有哪些原则？
选择性和唯一性：
优先为那些唯一性高或选择性好的列（即列中不同值的比例较高）创建索引。这可以确保索引的过滤效果更好，从而提高查询性能。
对于唯一性要求较高的列，可以考虑使用唯一索引或主键索引。
查询频率：
优先为那些经常用于查询条件的列创建索引。这可以加速查询速度，提高查询性能。
考虑查询的类型和复杂性，为经常用于连接（JOIN）、排序（ORDER BY）和分组（GROUP BY）的列创建索引。
索引大小：
尽量使用较短的索引列。较短的索引可以节省存储空间，并减少I/O操作，从而提高性能。
对于字符串类型的列，如果列的值较长，可以考虑使用前缀索引来减少索引的大小。
复合索引：
考虑使用复合索引（也称为联合索引或多列索引）来覆盖多个查询条件。这可以确保在查询时能够充分利用索引，减少回表操作，提高查询性能。
设计复合索引时，需要注意列的顺序和选择性。通常，将选择性好的列放在前面，以便更快地过滤数据。
避免冗余索引：
在设计索引时，要避免创建冗余的索引。冗余索引会浪费存储空间，并降低写操作的性能。
在创建新索引之前，检查现有的索引是否可以满足查询需求，避免重复创建类似的索引。
23、binlog、redolog和undolog区别？
执行 update 语句的过程与查询语句类似，分为连接器、分析器、优化器、执行器等阶段。在连接器的工作下，数据库连接建立后，通过执行器执行 update 操作。与查询不同的是，update 操作还涉及三个关键的日志文件：redo log、binlog 和 undo log。
redo log
redo log 是 InnoDB 存储引擎特有的物理日志，用于记录数据页的物理更改。
在执行 update 操作时，InnoDB 首先会修改内存中的数据页（Buffer Pool），然后将修改操作以物理日志的形式写入 redo log。
redo log 采用循环写的方式，由一组固定大小的文件组成，写满后会从头开始覆盖。
redo log 的写入分为 prepare 和 commit 两个阶段，配合 binlog 实现两阶段提交，保证数据库的 crash-safe 能力。
binlog
binlog 是 MySQL Server 层实现的逻辑日志，记录 SQL 语句的原始逻辑或行级变化（取决于 binlog_format 设置）。
每次 update 操作都会生成相应的 binlog 记录，主要用于主从复制和数据恢复等功能。
binlog 采用追加写入的方式，当一个文件写满时会切换到下一个文件，不会覆盖之前的记录。
两阶段提交
update 操作涉及两阶段提交机制，顺序为：先写 redo log 的 prepare 阶段，再写 binlog，最后写 redo log 的 commit 阶段。
这种机制保证了 redo log 和 binlog 的一致性，防止在异常重启或崩溃时导致数据库状态与恢复的数据不一致。
undo log
undo log 是 InnoDB 存储引擎的逻辑日志，用于记录数据修改前的值，主要用于事务回滚和多版本并发控制（MVCC）。
update 操作会生成相应的 undo log 记录，以便在事务回滚时恢复数据到修改前的状态，同时支持快照读。
undo log 默认存储在系统表空间中，也可以通过独立的 undo 表空间进行管理（MySQL 8.0 以后支持）。
rollback segment 用于管理 undo log，一个 rollback segment 包含多个 undo log segment，以支持高并发的事务操作。
24、SQL执行计划分析的时候，要关注哪些信息？
我们拿这段SQL列举一个例子
EXPLAIN SELECT *FROM archives执行结果如下

我们来解释下上述12个字段表示的意思。
id： 表示查询中执行计划中每个操作的标识符。如果查询是复杂的，可能会有多个操作。子查询的 id 是父查询的 id。
select_type： 描述查询的类型。常见的类型有：
simple：简单查询，不包含子查询或 union。
primary：查询中若包含任何复杂的子查询，最外层查询则被标记为 primary。
subquery：子查询。
derived：在 FROM 子句中派生的表，用于存储中间结果。
union：union 中的第二个及后续的查询。
table： 显示正在访问的表名。
partitions：当前操作所涉及的分区。
type： 表示连接类型或访问类型。常见的类型有：
ALL：全表扫描，逐行扫描整个表。
index：全索引扫描，遍历整个索引树。
range：范围扫描，只扫描给定范围的行。
ref：基于索引的等值查找。
eq_ref：类似于 ref，但使用的索引是唯一索引。
const：使用常量值匹配的情况。
system：表仅有一行（例如，系统表）。
possible_keys： 表示可能应用在这张表中的索引。这是一个表示可能索引选择的列表，但不一定会应用。
key： 实际使用的索引。如果为 NULL，则没有使用索引。
key_len： 表示索引中使用的字节数。较短的索引通常表示性能较好。
ref： 显示索引的哪一列被使用了，可能是一个常数值或者一个表达式。
rows： 估计的匹配行数，表示在执行查询时需要检查的行数。这是一个估算值。
partitions：当前操作所涉及的分区。
Extra： 包含额外的信息，可能包括以下一些项：
Using index：表示该查询使用了覆盖索引。
Using where：表示过滤条件使用了 WHERE 子句。
Using filesort：表示在排序时使用了文件排序。
Using temporary：表示使用了临时表进行排序。
Using join buffer：表示使用了连接缓存。
其中重点关注的字段有type、possible_keys、key、Extra ，面试的过程中主要讲解下这几个字段就可以了，其他字段作为了解。
25、MySQL死锁如何解决？
MySQL发生死锁通常涉及以下几个关键要素：
竞争资源： 多个事务同时尝试访问相同的资源，如数据库表、行、页或锁，但它们请求资源的顺序不同，导致彼此相互等待。、
未释放资源： 事务在使用完资源后未及时释放，使得其他事务无法获取所需的资源。这可能是由于程序中的错误或异常情况引起的。
事务执行速度差异： 如果某个事务在获取资源后执行速度较慢，而其他事务需要等待该事务释放资源，可能导致其他事务超时，从而发生死锁。
操作数据量过大： 在持有锁的同时，又请求获取更多的锁，导致彼此相互等待。
要解决或避免数据库死锁，可以采取以下方法：
降低锁的数量： 例如，使用读已提交（Read Committed）隔离级别替代可重复读（Repeatable Read），以规避由于间隙锁和next-key锁引起的死锁情况。
减少锁的持有时间：通过提高事务执行速度和降低事务执行时间，有效减少锁的持有时间，从而降低死锁发生的概率。
确立固定访问数据的顺序：当事务访问同一张表时，应确保以相同的顺序获取锁，以防止死锁的发生。
减少操作数据的量： 尽量减少事务操作的数据量，降低事务的持有时间，从而降低死锁的发生概率。
26、说说drop，truncate，delete区别
drop (删除表)：删除内容和定义，释放空间。drop语句将删除表的结构被依赖的约束（constrain),触发器（trigger)索引（index);依赖于该表的存储过程/函数将被保留，但其状态会变为：invalid。
truncate (清空表中的数据)：删除内容、释放空间但不删除定义(保留表的数据结构)
注意:truncate 不能删除行数据,要删就要把表清空。
delete (删除表中的数据)：delete 语句用于删除表中的行。delete语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存，以便进行进行回滚操作。
27、数据库死锁产生的原因，如何解决？(通用的数据库死锁，这个了解)
数据库死锁主要发生在多个进程或事务同时访问数据库资源时，由于每个进程或事务都持有其他进程或事务所需的资源，导致它们都无法继续执行下去，形成了一种相互等待的状态。具体来说，产生死锁的原因主要有以下几点：
系统资源不足：当数据库系统资源不足以满足所有进程或事务的需求时，就可能出现死锁。
进程运行推进的顺序不合适：如果进程或事务的执行顺序不当，可能导致它们互相等待对方释放资源，从而引发死锁。
资源分配不当：如果数据库系统对资源的分配不合理，也可能导致死锁的发生。
此外，产生死锁还需要满足以下四个必要条件：
互斥条件：一个资源每次只能被一个进程使用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不可剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。
循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。
解决数据库死锁的方法主要有以下几种：
预防和避免死锁：在系统设计、进程调度等方面注意如何不让产生死锁的四个必要条件成立。例如，可以尽量按照相同的顺序请求资源，避免循环等待；在分配资源时，可以一次性分配所有需要的资源，避免部分分配导致死锁等。
使用锁机制：包括乐观锁和悲观锁。乐观锁大多是基于数据版本记录机制实现，通过为数据增加一个版本标识来避免长事务中的数据库加锁开销。悲观锁则大多数情况下依靠数据库的锁机制实现，如Oracle的Select … for update语句，以保证操作最大程度的独占性。
检测并解除死锁：当检测到死锁发生时，数据库管理系统可以采取一些策略来解除死锁。例如，可以终止一个或多个进程或事务，以释放它们所持有的资源，从而打破死锁状态。
28、进行SQL调优的步骤？
定位低效SQL语句：
查看慢查询日志，这是优化过程中必看的日志，它可以帮助你定位那些执行效率较低的SQL语句。
使用SHOW PROCESSLIST命令查看当前MySQL的线程，这有助于你发现哪个数据库的等待时间较长。
分析SQL执行计划：
使用EXPLAIN语句来分析SQL语句的执行计划，这可以帮助你了解查询的执行过程，找到潜在的性能问题。
优化SQL语句：
针对定位到的低效SQL语句，根据执行计划的结果进行优化。优化方法包括但不限于：
建立物化视图或尽可能减少多表查询。
以不相干子查询替代相干子查询。
只检索需要的列，避免使用SELECT *。
用带IN的条件子句等价替换OR子句。
在经常查询的列上创建索引，提高查询效率。
避免使用模糊查询进行匹配，如果一定要使用，建议使用最左模糊匹配原则。
慢的查询的SQL，根据性能和存储容量大小进行评估，适当的可以考虑水平分表和垂直分表。
避免在列上使用函数或计算，这会导致索引失效。
优化数据库设计：
良好的数据库设计对于性能至关重要。你可以考虑以下建议：
增加内存，以便数据库可以缓存更多的数据和索引。
使用快速存储，如SSD，以提高磁盘I/O性能。
根据工作负载调整数据库配置设置，如缓冲池大小、连接数等。
考虑使用分布式数据库解决方案，以便在多个节点上分发数据和负载。
监控和分析：
持续监控和分析数据库性能是必不可少的。你可以使用性能监控工具定期检查数据库健康状况和性能指标。
分析慢查询日志，找出需要优化的查询。
定期审查和分析数据库模式，确保其仍然满足业务需求并保持高效运行。
定期进行数据库维护，如更新统计信息、重新建立索引等。
实施预防性措施，例如备份和恢复策略、安全措施等，以降低故障风险并确保数据可靠性。
29、MySQL 中 in 和 exists 的区别？
MySQL中的 in语句是把外表和内表作hash连接，而exists语句是对外表作loop循环，每次loop循环再对内表进行查询。我们可能认为 exists 比 in 语句的效率要高，这种说法其实是不准确的，要区分情景：
如果查询的两个表大小相当，那么用in和 exists 差别不大。
如果两个表中一个较小，一个是大表，则子查询表大的用 exists，子查询表小的用 in。
not in 和 not exists：如果查询语句使用了 not in，那么内外表都进行全表扫描，没有用到索引；而 not extsts 的子查询依然能用到表上的索引。所以无论那个表大，用 not exists 都比 not in 要快。
30、一条SQL 查询语句的执行顺序？

FROM：对FROM子句中的左表＜left_table＞和右表＜right_table＞执行笛卡儿积（Cartesianproduct），产生虚拟表 VT1
ON：对虚拟表 VT1 应用 ON 筛选，只有那些符合＜join_condition＞的行才被插入虚拟表 VT2 中
JOIN：如果指定了OUTER JOIN（如LEFT OUTER JOIN，RIGHT OUTER JOIN），那么保留表中未匹配的行作为外部行添加到虚拟表VT2中，产生虚拟表VT3。如果FROM子句包含两个以上表，则对上一个连接生成的结果表VT3和下一个表重复执行步骤1）~步骤3），直到处理完所有的表为止
WHERE：对虚拟表VT3应用WHERE过滤条件，只有符合＜where_condition＞的记录才被插入虚拟表VT4中
GROUP BY：根据 GROUP BY 子句中的列，对 VT4 中的记录进行分组操作，产生 VT5
CUBE|ROLLUP：对表VT5进行CUBE或ROLLUP操作，产生表VT6
HAVING：对虚拟表VT6应用HAVING过滤器，只有符合＜having-condition＞的记录才被插入虚拟表VT7中。
SELECT：第二次执行SELECT操作，选择指定的列，插入到虚拟表VT8中
DISTINCT：去除重复数据，产生虚拟表VT9
ORDER BY：将虚拟表VT9中的记录按照＜order_by_list＞进行排序操作，产生虚拟表VT10.11）
LIMIT：取出指定行的记录，产生虚拟表VT11，并返回给查询用户
31、binlog和redo log有什么区别？
redo log 是 InnoDB 引擎特有的，binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
redo log 是物理日志，记录的是“在某个数据页上做了什么修改”，binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如“给 ID=2 这一行的 c 字段加 1 ”
redo log 是循环写的，空间固定会用完，binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
redo log是用来保障已提交事务的ACID特性，binlog大多用于主从复制和数据恢复。
32、为什么日志需要“两阶段提交”？
什么是"两阶段提交？"
写入redolog的状态处于prepare阶段，然后写binlog，写完binlog后提交事务，并将redolog改为 commit状态。
为什么要"两阶段提交？"
防止写完redolog成功，还未写入binlog的时候宕机了的情况，这样重启后redolog里的数据还存在，可以恢复，但是从库都是拉的binlog，binlog里却丢失数据了。造成主从不一致，所以需要"两阶段提交"。
33、能简单说一下索引的分类吗？
主键索引：InnoDB主键是默认的索引，数据列不允许重复，不允许为NULL，一个表只能有一个主键。
唯一索引：数据列不允许重复，允许为NULL值，一个表允许多个列创建唯一索引。
普通索引：基本的索引类型，没有唯一性的限制，允许为NULL值。
组合索引：多列值组成一个索引，用于组合搜索，效率大于索引合并
34、索引哪些情况下会失效呢？
查询条件包含or，可能导致索引失效
如果字段类型是字符串，where 时一定用引号括起来，否则会因为隐式类型转换，索引失效
like通配符可能导致索引失效。
联合索引，查询时的条件列不是联合索引中的第一个列，索引失效。
在索引列上使用mysql的内置函数，索引失效。
对索引列运算（如，+、-、*、/），索引失效。
索引字段上使用（!= 或者＜＞，not in）时，可能会导致索引失效。
索引字段上使用is null，is not nul，可能导致索引失效。
左连接查询或者右连接查询查询关联的字段编码格式不一样，可能导致索引失效。
MySQL优化器估计使用全表扫描要比使用索引快，则不使用索引。
35、创建索引有哪些注意点？
索引应该建在查询应用频繁的字段。在用于where判断、order排序和join的（on）字段上创建索引。
索引的个数应该适量。索引需要占用空间；更新时候也需要维护。
区分度低的字段，例如性别，不要建索引。离散度太低的字段，扫描的行数降低的有限。
频繁更新的值，不要作为主键或者索引维护索引文件需要成本；还会导致页分裂，I0次数增多。
组合索引把散列性高（区分度高）的值放在前面为了满足最左前缀匹配原则
创建组合索引，而不是修改单列索引。组合索引代替多个单列索引（对于单列索引，MySQL 基本只能使用一个索引，所以经常使用多个条件查询时更适合使用组合索引）
过长的字段，使用前缀索引。当字段值比较长的时候，建立索引会消耗很多的空间，搜索起来也会很慢。我们可以通过截取字段的前面一部分内容建立索引，这个就叫前缀索引。
不建议用无序的值（例如身份证、UUID）作为索引。
36、Hash 索引和B+树索引区别是什么？
B+树可以进行范围查询，Hash索引不能。
B+树支持联合索引的最左侧原则，Hash索引不支持。
B+ 树支持 order by 排序，Hash 索引不支持。
Hash索引在等值查询上比B+ 树效率更高。
B+树使用like进行模糊查询的时候，like后面（比如%开头）的话可以起到优化的作用，Hash索引根本无法进行模糊查询。
37、buffer pool中数据页那么多，他怎么知道哪些是空闲的？（了解）
buffer pool里维护了一份free链表，free链表是个双向链表，里面放的是描述数据，描述数据里面包含页的位置，free链表里的节点都是空闲可用的。所以请求进来后将free链表里最后的node节点移除就好了，就代表此页已经被占用。等释放页的时候在加回free链表中。
38、怎么知道我此次请求对应的数据已经在buffer pool里了？（了解）
数据库有一个哈希表的数据结构，key是表空间号+数据页号，value是缓存页的地址。每次读取一个数据页到buffer pool之后，都会在这个 哈希表中写入一个key-value，下次再用这个数据页的时候就可以先从哈希表中直接读取出来他是不是已经放到buffer pool里了。
39、buffer pool中数据页那么多，他怎么知道哪个页是脏页要刷到磁盘上？（了解）
buffer pool里维护了一份flush链表，只要是被修改过的数据都会将其对应的描述数据加入到flush双向链表中，flush链表里的数据都是脏页，都是要被刷到磁盘上去的。刷到磁盘上后将此块描述数据从flush链表中移除，加入到free链表中，让其重新可用 。
40、lru链表、flush链表什么时候刷盘？（了解）
LRU链表
buffer pool没空闲缓存页的时候
有个后台线程每隔一段时间就会把lru冷数据区的尾部一些缓存页刷到磁盘，然后移除lru链表和 flush链表且加入到free链表
flush链表
buffer pool没空闲缓存页的时候从lru冷数据区移除数据且移除flush链表的数据
有个后台线程每隔一段时间就会把flush链表中的缓存页都刷到磁盘，然后移除lru链表和flush链表且加入到free链表
总结
后台线程不停的把flush链表和lru链表冷数据区的缓存页刷到磁盘上去，然后free链表中的缓存页不停的增加。这是个动态过程，并非要free不够了才刷盘释放缓存页。
41、MySQL主从复制原理的是啥？（了解）
主库将在每个事务提交之前将变更写入binlog
然后从库起一个I/O线程连接到master，master机器会为slave开启binlog dump线程。当master 的 binlog发生变化的时候，binlog dump线程会将binlog的内容发送给该I/O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log。
若读取的进度已经跟上了主库，那么就进入睡眠状态并等待主库产生新的事件。
最后从库中有一个SQL线程会从relay log里顺序读取日志内容并在从库中执行一遍，从而与主库的数据保持一致
42、如何解决MySQL主从同步的延时问题？（了解）
优化网络环境：主从复制时，网络延迟是一个重要因素。你可以考虑优化主从服务器之间的网络连接，比如增加带宽、减少网络抖动等。
增加从库数量：增加从库数量可以增加数据同步的速度和可靠性，同时也能减少每个从库的负担，提高从库响应速度。但是，请注意，这可能会增加系统的复杂性和维护成本。
调整数据库相关参数：
调整binlog格式：例如，使用ROW格式的binlog可以提高数据的一致性，但可能会增加网络传输的数据量。你可以根据实际情况选择合适的binlog格式。
调整binlog缓冲区大小：增加binlog缓冲区大小可以减少因binlog写入磁盘而产生的延迟。
调整innodb_flush_log_at_trx_commit：这个参数控制InnoDB日志的写入策略。将其设置为2可以减少I/O操作，但可能会增加数据丢失的风险。你需要权衡数据的安全性和性能来选择合适的值。
使用半同步复制：半同步复制介于异步复制和同步复制之间，主库在执行完事务后不立刻返回结果给客户端，需要等待至少一个从库接收到并写到relay log中才返回结果给客户端。这可以提高数据的可靠性和降低延迟。
分区数据库：将数据库分成多个区，每个从库只复制自己所需要的数据区，这样可以有效的减少排队堵塞、网络传输等方面的延迟问题。但是，这也可能会增加系统的复杂性和维护成本。
优化主从复制配置：你可以使用Percona Toolkit或pt-heartbeat等工具来监控主从延迟，并根据需要调整复制配置。例如，你可以调整从库的并行复制线程数（slave_parallel_workers参数）来加快从库的复制速度。
确保主从表结构一致：主从库之间的表结构必须保持一致，否则可能会导致同步失败或延迟。你可以使用pt-table-checksum等工具来检查主从库之间的数据一致性。
避免大事务和DDL操作：大事务和DDL操作可能会导致从库出现数据延迟。你可以尝试将大事务拆分成多个小事务，或者将DDL操作放在低峰时段执行。
为表创建主键或二级索引：如果表没有主键或二级索引，那么在进行DML操作时可能会产生大量的全表扫描，从而降低日志应用速度并产生数据延迟。你可以为所有表创建主键，或者在选择性高的列上创建二级索引。
43、为什么要分库分表？ （了解）
单机的存储能力、连接数、QPS是有限的，分库分表是一种很好的优化手段，将大表拆分到不同库不同表，减轻数据量，提高查询性能
44、分库分表的拆分方式有？他们分别主要解决什么问题？ （了解）
垂直拆分
把一个有很多字段的表给拆分成多个表，或者是多个库上去，每个库表的结构都不一样，每个库都都包含部分字段。一般来说会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。
水平拆分
表结构相同，拆分到多张表，这多张表可以在同一个库也可以在不同库，然后采取算法（比如哈希）将数据分散到多张表里，减轻单表的压力。
45、分库分表后面临的问题？（了解）
分布式事务问题 ：TCC、LCN、Seata、本地消息表、RocketMQ
分页、排序、跨库聚合统计等问题： 一般做法是分N次查询，然后业务代码里自己进行分页、排序或聚合
跨库join：一般做法是分N次查询，然后业务代码里自己组装数据
全局主键：
分布式id。UUID
数据库自增id
Redis
号段模式
雪花算法
美团Leaf：支持号段模式+雪花算法
46、如果某个表有近千万数据，CRUD比较慢，如何优化？（了解）
分库分表
某个表有近千万数据，可以考虑优化表结构，分表（水平分表，垂直分表），当然，你这样回答，需要准备好面试官问你的分库分表相关问题呀，如
分表方案（水平分表，垂直分表，切分规则hash等）
分库分表中间件（Mycat，sharding-jdbc等）
分库分表一些问题（事务问题、分布式id、跨节点Join等问题）
解决方案（分布式事务等）
索引优化
除了分库分表，优化表结构，当然还有所以索引优化等方案。

1、为什么要用MQ
在分布式系统下具备异步、削峰、解耦等功能。
拥有持久化的机制，进程消息、队列中的信息也可以保存下来；
实现消费者和生产者之间的解耦；
对于高并发场景下，利用消息队列可以使得同步访问变为串行访问达到一定量的限流，利于数据库的操作；
可以使用消息队列达到异步下单的效果，排队中，后台进行逻辑下单；
2、RabbitMQ的组成成分和工作原理

生产者(Producer)、信道(Channel)、交换机(Exchange)、绑定(Binding)、队列(Queue)、消费者(Consumer)。
生产者通过信道把消息发送给交换机，交换机接收消息并且对消息进行路由，交换机绑定队列并根据路由键来把消息分发到不同的队列上，消息会一直留在队列里直到被消费者消费。
3、常用的交换机有哪几种
Direct(默认)：一对一、点对点的发送，定向把消息交给符合指定routing key 的队列；
Fanout：广播，将消息交给所有绑定到交换机的队列；
Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列；
Routingkey 一般都是由一个或多个单词组成，多个单词之间以”.”分割，例如: item.insert
通配符规则：
：匹配一个或多个词
*：匹配不多不少恰好1个词
4、如何保证消息不丢失
消息丢失的原因：网络问题。网络发生故障、丢包造成消息丢失。
生产者丢失：将信道设置成confirm模式。生产者通过调用chamnel.confimSelect方法将信道设置为confmm模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始)，一消息被投递到所有匹配的队列之后，RabbitMQ就会发送一个确认 (Basic.Ack) 给生产者；
mq中丢失：做消息的持久化。避免RabbitMQ把消息弄丢,发消息前,将消息持久化到数据库，并记录消息状态。
前提是：队列和交换机也都进行了持久化.(因为消息都经历了队列和交换机,中途也可能发生消息的丢失)
消费者丢失：手动ACK。消费端默认是自动ack的，这样生产者在发送完消息就把消息标记为清除，改成手动ack,当消息正确处理完再通知mq清除消息；当消费端处理异常的时候回传nack，这样mq会把这个消息投递到另外一个消费者。
手动Ack：主要是确认消息被消费者消费完成后通知服务器将队列里面的消息清除
5、如何防止消息重复消费
什么是消息重复消费？首先我们来看一下消息的传输流程。消息生产者--＞MQ--＞消息消费者；消息生产者发送消息到MQ服务器，MQ服务器存储消息，消息消费者监听MQ的消息，发现有消息就消费消息。所以消息重复也就出现在两个阶段:
生产者多发送了消息给MQ：在消息生产时， MQ 内部针对每条生产者发送的消息生成⼀个 inner-msg-id，作为去重和幂等的依据（消息投递失败并重传），避免重复的消息进⼊队列；
MQ的一条消息被消费者消费了多次：在消息消费时，要求消息体中必须要有⼀个 bizId(对于同一业务全局唯一，如支付id 、订单id 、帖子id 等)作为去重和幂等的依据，避免同⼀条消息被重复消费。
6、RabbitMQ的死信队列
死信队列：当消息在一个队列中变成无法被消费的消息之后，它能被重新投递到另一个交换机，这个交换机就是死信队列。
消息变成死信的几种情况：
消息被拒绝（channel.basicReject/channel.basicNack）并且request=false；
消息在队列的存活时间超过设置的生存时间（TTL）时间；
队列达到最大长度（队列满了，无法再添加数据到队列中）。
死信队列也是一个正常的交换机，和一般的交换机没有区别，它能在任何的队列上被指定，实际上就是设置某个队列的属性。
死信队列的设置：
首先，需要设置死信队列的交换机和队列，然后进行绑定；
然后，我们声明正常交换机、队列，再绑定，只不过我们需要在队列机上一个参数：arguments.put(“x-dead-letter-exchange”,”dlx.exchange”)；这样消息在过期、被拒绝、队列在达到最大长度时，消息就可以直接路由到死信队列。

7、RabbitMQ如何实现延迟消息的
通过死信队列来实现，创建一个正常的队列和一个死信队列，在发送消息时，设置消息的生存时间TTL（Time-To-Live），如果消息在正常队列中过期，会被转发到死信队列，创建一个消费者来监听死信队列，处理延迟消息。
RabbitMQ提供了一个名为rabbitmq_delayed_message_exchange的插件，可以用来实现延迟消息。
8、消息长时间堆积怎么处理
临时扩容，以更快的速度去消费：修复并停掉 consumer，新建⼀个 topic，partition是原来的10倍，建⽴临时queue，数量是原来的10倍或20倍，写临时 consumer 程序，临时征用10倍的机器去消费数据，消费完成之后，恢复原来的consumer。
消息重发：RabbitMQ如果设置了过期时间，消息积压之后，过了这个时间就过期被清理了，所以消息就直接丢失了。就只能再重新补数据，在流量低峰期的时候写一个程序手动查询丢失的那部分数据，将消息重新发送到mq里，重新消费。
如果是积压的消息太多没消费，然后MQ放不下这么多消息导致后面的消息直接被丢弃。就结合上面两种方式去处理。
9、RabbitMQ集群
普通集群模式
普通集群模式是一种将多个RabbitMQ实例部署在不同服务器上，这些实例之间协同工作，共享队列和交换机的元数据，并通过内部通信协议来协调消息的传递和管理。
在这种模式下，我们可以创建队列Queue，其元数据（配置信息）会在集群中的所有实例之间同步。但是队列中的消息只会存在于一个RabbitMQ实例上，而不会同步到其他队列。这个实例通常被称为消息所在的“主节点”或“主实例”。
当我们消费消息时，如果消费者连接到了不保存消息的实例，那么该实例会通过元数据信息定位消息所在的主节点，并将数据拉取到该实例，然后发送给消费者进行处理。发送消息也是类似的，当发送者连接到一个不保存消息的实例时，消息会被转发到主节点进行写操作。
在这种集群模式下，每个实例的元数据是相同的，它们都具有相同的队列和交换机配置。但是队列中的消息数据在不同的实例上是不同的，它们仅存在于主节点上。通过增加实例的方式，可以提升整个集群的消息存储容量和处理性能。
这种集群模式提高了高可用性，因为即使某个实例出现故障，其他实例仍然可以继续提供服务。但它的一个主要限制是无法在每个实例上读取和写入消息数据，只有主节点上可以进行消息的读写操作。这可能导致在消息数据所在的主节点上出现瓶颈，尤其在大量消息处理的情况下。

镜像队列模式
镜像队列模式下，每个RabbitMQ实例都像镜像一样，存储的内容都是相同的。在这种模式下，队列的元数据和消息数据不再是单独存储在某个实例上，而是集群中的所有实例上都存储一份。
每次在消息写入时，需要在集群中的所有实例上都同步一份消息数据和元数据。这样，即使其中一台实例发生故障，剩余的实例也可以继续提供完整的数据和服务。这种模式提高了消息队列的高可用性，因为消息数据在集群中的多个实例上都有备份，不会因单个节点的故障而导致消息的丢失。

IT枫斗者介绍
关于我们介绍
大家好，我是 IT 枫斗者团队的程序员枫哥，🌟 阿里云技术专家、📝 资深面试官、🌹 Java跳槽网课堂创始人。拥有多年一线研发经验，曾就职于科大讯飞、美团网、平安等公司。
需要看面试实战视频可以关注 B 站号：IT 枫斗者–Java面试。
技术文章可关注 CSDN（全栈领域优秀创作者、技术专家博主、百万+访问量）：IT 枫斗者。
联系枫哥或语音/电话沟通请看底部联系方式。
目前组建的技术团队，专注 Java 技术分享，一对一学习辅助，春招/秋招/社招/跳槽等求职辅助。
自 2017 年底开始做面试辅导，辅导成功上岸学员 3000+。底部有我们的八年辅导历程，八年风雨不忘初心！
这是一个面向就业指导的训练营，真正做到保姆式一对一面试辅导，快速拿到 offer。

我们能给你带来什么？
我们这里可以提供 40 多个大型的企业级互联网项目经验可选（都是技术老师真实接触的：非电商类、非物流外卖等）。不同情况匹配不同项目经验，不同工作年限负责模块和深度也不一样。
企业级项目经验答疑，一直到你能专业并熟练表达为止。
讲清楚项目真实开发迭代过程、业务逻辑和技术实现细节，整理出项目文档和技术亮难点。
一对一解答服务，实战面试总结，面试过程你不是一个人在战斗，我们都在！
简历个性化代写，根据需求动态调整简历，直到有效果为止！
还原真实面试现场，直到你能达到实战面试要求为止，不停总结和解决问题！
项目经验准备周期约一周，助力你快速入职！
一次性收费无需其他费用，辅导经验和大型互联网项目经验不是别人能比的！我们 2017 年就开始，同行都还没毕业！
最终目的是负责你收到 offer 为止。因为是企业级真实项目经验，我们整理了大量亮点和难点，并有负责模块的伪代码和详细技术文档/视频讲解，支持不限次数 1V1 腾讯会议讲解，确保你面试能说得出来！
关于保障： 只要你配合且信息真实，我们肯定能给你一个结果！

辅导内容及服务流程
offer 突击训练营是针对找工作的同学，给你一个 offer 保障！
面试知识体系我们会监督你每天学习。
项目方面：技术点、业务功能、真实开发过程全详细教学，不让你耗时间写代码，有针对性应对面试。
提供真实项目经验，保证面试有内容可讲。
服务流程
1v1辅导群，摸底能力测评，定制面试学习计划
知识体系包含：Java基础、Jvm、Mysql、Spring全家桶、Redis、MQ、设计模式、算法、大厂项目
每日问题总结，1V1腾讯会议解答、1V1语音电话解答、1V1日报问题文档解析
个性化简历代写、匹配企业级真实项目，配套项目讲解答疑、两轮模拟面试（多次技术栈面、多次项目面）
讲解简历投递策略，HR沟通技巧、1V1面试复盘，offer决策指导
套餐内容和服务流程如下

大厂成功案例
我们的学员成功拿到 [字节、阿里、美团、腾讯、百度、京东、快手、滴滴、华为、网易、拼多多、B站、小米、携程、开课吧、途虎] 等大厂 offer！

近期成功案例

经典成功案例
一年Java开发，本科，拿到华为od录用18k

逆袭大厂手撕算法，拿下滴滴offer入职34k

一年工作经验，本科，没有项目可以面试，最终拿下5个offer，总结出5个面经

学历差？成人大专逆袭税后14.5K的offer已经成功入职！
很多小伙伴觉得学历不好没有面试机会，其实“难”并不代表没机会。针对学历不占优势的，一定要从技术栈和项目经验上下功夫，突出能力！有经验后学历不再是绊脚石。

硕士应届生秋招，拿到深信服19k*15薪，年终0-6个月，600餐补

工作好几年薪资涨幅低，想跳槽又怕没准备好
在普通公司干了几年，薪资涨幅低又没技术提升，面试题、面试技巧、项目经验都不知如何准备——以下几位都已成功跳出舒适圈！

经朋友介绍辅导，最终年薪30w

零基础自学，第一个offer：青岛，年包24-25万；第二个offer：北京，15.5*13薪
2024年研究生毕业，自己秋招不顺利，后找到我们定制计划，最终拿下两个 offer。

只会基础到大厂度小满1515k的offer
大四在校生基础薄弱，通过秋招训练营坚持不懈，最终收到度小满 offer，薪资15k15薪！

九年开发经验，从坑出发，最终拿下外企16K*14薪，朝九晚六双休不加班

函授本科，培训，半年多Java开发经验，西安10k 朝九晚六双休

民办本科非计算机自学转行拿到15k14的offer
2019年毕业，油气储运工程专业，做销售转自学 Java，一年后跳槽拿到15k14的 offer！

深圳，三个offer，普通二本生物自学
2020年毕业，生物专业自学，原简历投数百份仅获两个面试，项目经验是最大痛点。后通过我们定制方案，拿下三个 offer！

培训出来经包装拿下四个offer，最高18k*15薪
培训结束后毫无项目经验，经过我们辅导，成功拿到四个 offer！

刚自学完，对面试非常惶恐，担心找不到工作？

深信服26k15薪，会问哪些技术？三年经验几轮面试
最近面试总结采访，三年经验，顺利斩获26k15薪 offer！

北京，30k*12薪
实际经验四年多，包装成五年多，hr面问什么也有总结

两个offer，上海11k && 湖南数字马力12k

三个offer，17k的银行外包，14.5k的阿里，中证18k，季度奖4-8k，每月休息九天

就业陪跑八年历程（八年风雨，不忘初心）
坚持做一件事八年很难，枫哥坚持做辅导八年，同行很多人还在上大学。只要互联网行业不崩，我们一直都在。
2018年（八年风雨，不忘初心）
写帖子、CSDN、技术平台文章，得到小伙伴肯定，找到做辅导的意义！

2019年辅导记录
面试辅导套餐、简历定制套餐上线，开淘宝店保障学员交易，每月都有进大厂的学员。

2020年辅导记录
疫情转折点，在线教育火了，上线私教带徒套餐和学习网站，团队迎来新成员。

2021年辅导记录
品牌保护，注册商标，技术老师统一头像，防止盗图。

2022年辅导记录
团队壮大，新增丙丙老师，枫哥亲自体验国企和事业单位考试，分享考证领补贴经验。

2023年辅导记录
互联网行业寒冬，枫哥全职面试辅导，开启直播，团队再扩张。

2024年辅导记录
专注心理辅导，鼓励学员调整心态，行情再差也能找到工作，团队又加入彬哥。

2025年辅导记录
团队最强阵容，面试超神之路资料开源。2025年上半年辅导91个学员，86人收到offer，就业率96%！

如何报名？
如需报名或咨询，请加 枫哥微信：itfdz666，加时备注：报名。

更多信息请关注 B 站/知乎/CSDN 及下方联系方式。

Redis
1、Redis支持哪些数据类型及应用场景？
String：字符串、整数、浮点型，可用于计数器、分布式锁
Hash：包含键值对的无序散列表，可用于存储用户信息对象(User对象)
List：列表，可用于存储集合，消息队列
Set：无序集合不可重复，可用于好友关系(Set交并差集)
Zset：有序集合不可重复，可用于排行榜（zset的score）
2、缓存和数据库的一致性
如果业务量不大，并发不高的情况，可以选择先更新数据库，后删除缓存的方式
业务量比较大，并发度很高的话，那么建议选择先删除缓存，先删除缓存有两种方案：
延时双删：先删缓存再更新数据库，再延时删除缓存(比如休眠500ms再删)，然后再写入缓存
分布式锁：删除缓存，对key加锁，更新数据库再写缓存，再释放锁
3、Redis的持久化机制
持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。RDB（默认）和AOF两种。
rdb是在一定的间隔时间中(几分钟，几小时。几天)，检测key的变化情况，然后生成快照持久化数据到磁盘中；
AOF是日志记录的方式，可以记录每一条命令的操作。可以每一次命令操作后，通过一个后台线程执行一次fsync操作，持久化数据。
如何选择：
RDB 二进制存储节省空间，只有一个dump.rdb文件。灾难恢复较快。性能最大化（主进程处理命令的效率，而不是持久化的效率），采取的是fork()+copyonwrite技术。 但是安全性相对较低，因为rdb是每隔一段时间进行持久化，数据丢失率较高。持久化速度相对aof较低，因为aof直接append追加，rdb是全量。
AOF数据安全，可以配置always，也就是每进行一次命令操作就记录到aof文件中一次。持久化速度较快，每次都只是追加一个语句到文件，带rewrite机制。AOF 文件比 RDB 文件大，所以灾难性恢复速度慢。会对主进程对外提供请求的效率造成影响，接收请求、处理请求、写aof文件这三步是串行原子执行的。而非异步多线程执行的。Redis单线程！
Redis4.0后支持混合持久化，也就是rdb+aof可以同时开启，然后使用AOF来重建数据，因为AOF中的数据更加完整，让rdb作为冷备份。
4、Redis中key的过期策略
定期删除：指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。
惰性删除：定期删除可能会导致很多过期key到了时间并没有被删除掉，那么惰性删除就是在你获取某个key的时候，redis会检查一下 ，这个key如果过期了就删除，不会给你返回任何东西。
5、Redis的淘汰策略（了解）
如果redis的内存占用过多的时候，此时会进行内存淘汰策略。
volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰；
volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰；
volatile-random：从已设置过期时间的数据集中任意选择数据淘汰；
allkeys-lru：从数据集中挑选最近最少使用的数据淘汰；
allkeys-random：从数据集中任意选择数据淘汰；
no-enviction：不淘汰任何键值对，直接返回错误信息；（默认）
6、缓存雪崩、缓存穿透、缓存击穿、缓存预热、缓存降级
缓存雪崩：缓存大面积同时间段失效 ，请求都去查询数据库了，对数据库CPU和内存造成巨大压力。
解决办法：
将缓存失效时间分散开；
考虑用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
缓存穿透：缓存穿透指的是当查询一个数据库中不存在的数据时，由于缓存层没有存储这个数据的记录（即缓存未命中），因此每次查询都会穿透到数据库层，导致数据库承受不必要的压力。
解决办法：
采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
也可以将查询返回的数据为空的这个结果进行缓存，过期时间设置短一点短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库。
缓存击穿：某个 key 非常热点，访问非常的频繁，高并发访问的情况下，当这个 key在失效的瞬间，大量的请求进来，这时候就击穿了缓存，直接请求到了数据库。
解决办法：
热点数据永不过期。
分布式锁，来个请求先锁住，然后去db查，查到后再将数据set到redis里。只有当redis里getKey没拿到数据需要请求db的时候才加锁。
缓存预热：就是系统启动的时候就查询数据库将相关的数据直接缓存到Redis中。这样可以避免用户查询的时候先判断是否有缓存，没的话在查db进行缓存等一系列操作了。
实现方案
如果数据量不大的话，可以在项目启动的时候进行缓存。
如果数据量很大的话可以写个简易的页面，上线时手工点一下进行缓存。
定时任务定时刷新缓存。
缓存降级：就是当缓存出故障的时候，别影响主业务系统，让他可以继续对外提供服务
实现方案
很简单，在catch里去查db，而不是抛出异常。
利用熔断降级组件返回错误码。
7、Redis是单线程的吗
Redis是单线程的，Redis用一个线程来处理所有的请求和操作。
Redis 之所以选择单线程的设计，因为它是一个基于内存的存储系统，而且它的瓶颈通常在于 CPU 的速度而不是多核的并发。通过使用单线程，Redis 简化了并发控制和数据结构的实现，避免了多线程的复杂性和线程安全的问题，通过多路复用 I/O模型能够在单线程中处理大量的并发连接。
Redis 也提供了一些多线程的功能，比如AOF、RDB 持久化以及从节点复制可以在其他线程中执行。
8、Redis的setnx命令原理（重要）
SETNX即Set if Not eXists，setnx是redis的一个命令，它会检查指定的键是否已经存在于数据库中，如果键不存在，则将该键设置指定的值，并返回1，表示操作成功。如果键已经存在，SETNX命令将不执行任何操作，返回0，表示操作失败。
这个原理保证了在多个客户端同时尝试设置同一个键时，只有一个客户端能够成功执行设置操作，其他客户端将得到失败的返回值。这使得setnx 可以用于实现分布式锁。
9、列举几个Redis应用场景？
计数器
数据缓存
页面缓存
消息队列（blpop）
分布式锁
好友关系（set交并差集）
排行榜（zset的score）
10、Redis线程模型知道吗？(了解)
redis 内部使用文件事件处理器 file event handler，它是单线程的，所以redis才叫做单线程模型。它采用IO多路复用机制同时监听多个 socket。多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理。

11、RDB持久化的原理是怎样的？（了解）
RDB（Redis DataBase）持久化的原理主要是通过在指定的时间间隔内，将内存中的数据集快照（Snapshot）写入到磁盘中，以保存为rdb文件的形式。这个过程是通过fork一个子进程来完成的，子进程会共享父进程的内存数据，然后遍历整个内存数据，将数据写入到一个临时文件中。当持久化过程结束后，会用这个临时文件替换上一次的持久化文件（rdb文件）。
在RDB持久化的过程中，主进程（父进程）仍然可以继续处理客户端的请求，而子进程则负责完成持久化的工作。由于子进程是父进程的一个副本，因此它包含了父进程在fork时刻的内存数据状态。所以，即使主进程在持久化过程中继续处理请求并修改了数据，这些修改也不会影响子进程进行持久化的数据状态。
RDB持久化的优点在于它生成的文件是一个紧凑的二进制文件，可以很方便地进行备份和传输。而且，由于它是基于快照的持久化方式，因此可以很好地支持数据的恢复。但是，RDB持久化也有一些缺点。首先，由于它是在某个时间点上对整个内存数据进行快照，因此可能会丢失在这个时间点之后的数据修改。其次，在进行RDB持久化时，会消耗一定的系统资源（如CPU和内存），可能会影响Redis的性能。
12、为什么要用copyonwrite？（了解）
假设是全量复制，那么内存空间直接减半，浪费资源不说，数据量10g，全量复制这10g的时间也够长的。这谁顶得住？
如果不全量复制，会是怎样？相当于我一边复制，你一边写数据，看着貌似问题不大，其实不然。比如现在Redis里有k1的值是1，k2的值是2，比如bgsave了，这时候rdb写入了k1的值，在写k2的值之前时，有个客户端请求
那么持久化进去的是k2 22，但是k1的值还是1，而不是最新的11，所以会造成数据问题，所以采取了copyonwrite技术来保证触发bgsave请求的时候无论你怎么更改，都对我rdb文件的数据持久化不会造成任何影响。
13、AOF持久化的原理是怎样的？(了解)
就是每次都在aof文件后面追加命令。他与主进程收到请求、处理请求是串行化的，而非异步并行的。图示如下：

所以aof的频率高的话绝逼会对Redis带来性能影响，因为每次都是刷盘操作。跟mysql一样了。Redis每次都是先将命令放到缓冲区，然后根据具体策略（每秒/每条指令/缓冲区满）进行刷盘操作。如果配置的always，那么就是典型阻塞，如果是sec，每秒的话，那么会开一个同步线程去每秒进行刷盘操作，对主线程影响稍小。
14、Redis的事务概念和原理
Redis的事务并不像Mysql那么灵活，有隔离级别，出问题后还能回滚数据等高级操作。Redis毕竟是非关系型数据库，他目前事务回滚机制是不执行命令，也就是可以采取watch命令模拟乐观锁，进行监听数据，发现数据不是事务开始时候的样子了，那么我这个事务里的命令就不会得到执行。
原理：
watch
每个数据库都维护一个字典watched_keys，key为监听的key，value即为监听的客户端对象。 所有客户端的修改都会去检查这个字典，如果key一致则会去打开客户端对象的 REDIS_DIRTY_CAS.
multi 和 exec
multi命令将客户端标记为“事物状态”，这个客户端后续的普通操作指令都会放入事务队列（客户端会保存一个事务队列），直到执行multi、exec、watch（？）、discard。
exec时会服务端去查当前客户端的REDIS_DIRTY_CAS，如果被打开了，则拒绝客户端提交的事务。没打开则遍历客户端事务队列，挨条执行。
15、Redis的哨兵机制
哨兵的核心功能：在主从复制的基础上，哨兵引入了主节点的自动故障转移。
Sentinel 定期向 Redis 主从节点发送 ping 命令，检查节点的健康状况。通过监测节点的响应时间和是否能够正常处理命令，Sentinel 可以判断节点的状态，通过多个哨兵之间的协商来达成一致的判断。当一个哨兵认为某个节点可能故障时，它会将该节点标记为主观下线，当多个哨兵都认为某个节点都下线时，该节点才被判断为客观下线。
当节点被判断为客观下线时，Sentinel 会发送通知，通知其他 Sentinel 和客户端。Sentinel 在发现主节点故障时，会从当前的从节点中投票选举一个新的主节点，再更新配置。这确保了整个 Redis 集群在主节点故障后的自动恢复。
16、Redis主从复制(了解)
主从复制是指将一台 Redis 服务器的数据复制到其他的 Redis 服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。 默认情况下，每台 Redis 服务器都是主节点，且一个主节点可以有多个从节点 (或没有从节点)，但一个从节点只能有一个主节点。
主从复制实现了数据的热备份；当主节点出现问题时，可以由从节点提供服务，实现故障的快速恢复；在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 (即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点)，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。主从复制是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
主从复制的原理：若启动一个Slave机器进程，则它会向Master机器发送一个“sync command" 命令，请求同步连接。无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中(执行rdb操作) ，同时 Master 还会记录修改数据的所有命令并缓存在数据文件中。后台进程完成缓存操作之后，Master 机器就会向 Slave 机器发送数据文件，Slave 端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着 Master 机器就会将修改数据的所有操作并发送给 Slave 端机器。若 Slave 出现故障导致宕机，则恢复正常后会自动重新连接。Master机器收到 Slave 端机器的连接后，将其完整的数据文件发送给 Slave 端机器，如果 Mater 同时收到多个 Slave 发来的同步请求，则 Master 会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的 Slave 端机器都正常。
17、Redis的集群（了解）
什么是 Redis 集群
简单理解，Redis 集群是由多个 Redis 实例协同工作，以完成相同的任务或在高并发情况下分担负载。它不仅能够代替主节点（Master）成为新的主节点以继续任务，还能保持数据的完整性和一致性。
Redis 的部署模式
Redis 提供了以下三种主要的部署模式，以满足不同的高可用性和扩展性需求：
主从复制模式（Master-Slave Replication）
哨兵模式（Sentinel Mode）
集群模式（Cluster Mode）

1. 主从复制模式（Master-Slave Replication）
   描述：
   主节点（Master）：负责处理所有的写操作和部分读操作。
   从节点（Slave）：复制主节点的数据和状态信息，仅用于数据备份和分担读请求。
   特点：
   数据冗余：通过多个从节点备份主节点的数据，提高数据的可靠性。
   读写分离：将读请求分发到从节点，提升读性能。
   手动故障切换：当主节点故障时，需要手动将某个从节点提升为新的主节点。
   适用场景：
   数据备份和恢复。
   读操作较多的应用，通过从节点分担读压力。
2. 哨兵模式（Sentinel Mode）
   描述：
   基于主从复制模式，增加了 哨兵（Sentinel） 节点来监控 Redis 集群的状态。
   哨兵节点负责自动检测主节点的故障，并在故障发生时自动进行主从切换。
   特点：
   高可用性：自动故障检测与切换，减少人工干预。
   监控与通知：实时监控 Redis 节点的状态，并在必要时发送通知。
   不支持数据分片：仍然受限于单机的存储容量。
   适用场景：
   需要高可用性的应用，但数据量在单机可承受范围内。
   希望简化运维，减少手动故障处理的场景。
3. 集群模式（Cluster Mode）
   描述：
   Redis Cluster 通过 数据分片（Sharding） 将数据分布到多个主节点，每个主节点可以有一个或多个从节点。
   集群中的每个主节点负责部分键空间，实现水平扩展。
   特点：
   数据分片：打破单机内存限制，将数据分布到多个节点，支持更大规模的数据存储。
   高性能：多个主节点并行处理请求，提高整体吞吐量。
   高可用性：支持主节点的自动故障转移，每个主节点的从节点可以接管其任务。
   负载均衡：读写请求可以分布到不同的主节点，提升整体性能。
   复杂性增加：需要更多的配置和管理，节点之间需要协调一致。
   适用场景：
   大规模数据存储和高并发访问需求。
   需要分布式存储和高可用性的应用。
   需要扩展 Redis 集群以应对增长的数据量和流量。
   三种模式的比较
   主从复制模式（Master-Slave Replication）
   优势：数据备份、读写分离、配置简单。
   劣势：主节点故障时需要手动切换，写操作无法负载均衡，存储能力受限于单机。
   哨兵模式（Sentinel Mode）
   优势：基于主从复制，自动故障恢复，提高高可用性，减少人工干预。
   劣势：写操作无法负载均衡，存储能力受限于单机，不支持数据分片。
   集群模式（Cluster Mode）
   优势：实现数据分片和负载均衡，突破单机存储限制，支持高并发和高性能，具备较完善的高可用方案。
   劣势：配置和管理复杂，节点之间需要良好的协调机制。
   18、Redis的脑裂
   某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master也就是所谓的脑裂。
   解决方案：
   min-replicas-to-write 3 //与主节点通信的从节点数量必须大于等于该值主节点，否则主节点拒绝写入
   min-replicas-max-lag 10 //主节点与从节点通信的ACK消息延迟必须小于该值，否则主节点拒绝写入
   按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，故障期间满足min-slaves-to-write和min-slaves-max-ag的要求，那么主节点就会被禁止写入，脑裂造成的数据丢失情况自然也就解决了。
   19、哨兵之间是怎么发现彼此的 ？（了解）
   是通过PSUBSCRIBE这个Redis内置的发布订阅命令来实现的，他们共同监听 sentinel:hello 这个channel，每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的__sentinel__:hello channel 里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置，每个哨兵也会去监听自己监控的每个master+slaves对应的 sentinel:hello channel ，然后去感知到同样在监听这个master+slaves的其他哨兵的存在，每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步。
   20、如何优化Redis内存？
   选择合适的数据类型
   大value选择gzip压缩
   避免使用大key
   批处理采取Pipeline（小心配置单次pipeline命令总大小，不要撑爆socket缓冲区）
   21、Redis为什么这么快？（了解）
   纯内存操作，且时间复杂度大多都是O(1)，也有特例，比如zset底层跳表是log(n)，keys....等！
   数据结构底层存储的设计比较节省空间
   采取单线程避免了不必要的上下文切换。
   采取I/O多路复用，epoll模型，非阻塞IO。
   22、五种数据类型的底层存储原理是什么？（了解，跳表需要重点看下）
   string：int、raw、embstr
   list：ziplist、linkedlist
   hash：ziplist、hashtable
   set：intset、hashtable
   sorted set：ziplist、skiplist+dict

1、MQ的作用是什么呢？
因为项目比较大，做了分布式系统，所有远程服务调用请求都是同步执行经常出问题，所以引入了mq
2、RocketMQ由哪些角色组成，每个角色作用和特点是什么？

3、RocketMQ Broker中的消息被消费后会立即删除吗？（了解）
不会，每条消息都会持久化到CommitLog中，每个Consumer连接到Broker后会维持消费进度信息，当有消息消费后只是当前Consumer的消费进度（CommitLog的offset）更新了。
4、RocketMQ消费模式有几种？
集群消费：
一条消息只会被同Group中的一个Consumer消费
多个Group同时消费一个Topic时，每个Group都会有一个Consumer消费到数据
广播消费：
消息将对一 个Consumer Group 下的各个 Consumer 实例都消费一遍。即即使这些 Consumer
属于同一个Consumer Group ，消息也会被 Consumer Group 中的每个 Consumer 都消费一 次。
5、如何保证消息不丢失（了解）
消息可能在哪些阶段丢失呢？可能会在这三个阶段发生丢失：生产阶段、存储阶段、消费阶段。所以要从这三个阶段考虑：

生产
在生产阶段，主要通过请求确认机制，来保证消息的可靠传递。
同步发送的时候，要注意处理响应结果和异常。如果返回响应OK，表示消息成功发送到了Broker，如果响应失败，或者发生其它异常，都应该重试。
异步发送的时候，应该在回调方法里检查，如果发送失败或者异常，都应该进行重试。
如果发生超时的情况，也可以通过查询日志的API，来检查是否在Broker存储成功。
存储
存储阶段，可以通过配置可靠性优先的 Broker 参数来避免因为宕机丢消息，简单说就是可靠性优先的场景都应该使用同步。
消息只要持久化到CommitLog（日志文件）中，即使Broker宕机，未消费的消息也能重新恢复再消费。
Broker的刷盘机制：同步刷盘和异步刷盘，不管哪种刷盘都可以保证消息一定存储在pagecache中（内存中），但是同步刷盘更可靠，它是Producer发送消息后等数据持久化到磁盘之后再返回响应给Producer。
Broker通过主从模式来保证高可用，Broker支持Master和Slave同步复制、Master和Slave异步复制模式，生产者的消息都是发送给Master，但是消费既可以从Master消费，也可以从Slave消费。同步复制模式可以保证即使Master宕机，消息肯定在Slave中有备份，保证了消息不会丢失。

消费
从Consumer角度分析，如何保证消息被成功消费？
Consumer保证消息成功消费的关键在于确认的时机，不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。因为消息队列维护了消费的位置，逻辑执行失败了，没有确认，再去队列拉取消息，就还是之前的一条。
6、如何防止消息重复消费（了解）
对分布式消息队列来说，同时做到确保一定投递和不重复投递是很难的，就是所谓的“有且仅有一次” 。RocketMQ择了确保一定投递，保证消息不丢失，但有可能造成消息重复。处理消息重复问题，主要有业务端自己保证，主要的方式有两种：业务幂等和消息去重。
业务幂等：第一种是保证消费逻辑的幂等性，也就是多次调用和一次调用的效果是一样的。这样一来，不管消息消费多少次，对业务都没有影响。
消息去重：第二种是业务端，对重复的消息就不再消费了。这种方法，需要保证每条消息都有一个唯一的编号，通常是业务相关的，比如订单号，消费的记录需要落库，而且需要保证和消息确认这一步的原子性。
具体做法是可以建立一个消费记录表，拿到这个消息做数据库的insert操作。给这个消息做一个唯一主键（primary key）或者唯一约束，那么就算出现重复消费的情况，就会导致主键冲突，那么就不再处理这条消息。
7、如何让RocketMQ保证消息的顺序消费？
首先多个queue只能保证单个queue里的顺序，queue是典型的FIFO，天然顺序。多个queue同时消费是无法绝对保证消息的有序性的。所以总结如下：
同一topic，同一个QUEUE，发消息的时候一个线程去发送消息，消费的时候 一个线程去消费一个queue里的消息。

8、Broker把自己的信息注册到哪个NameServer上？
这么问明显在坑你，因为Broker会向所有的NameServer上注册自己的信息，而不是某一个，是每一个，全部
9、RocketMq的工作流程是怎样的？（了解）
首先启动NameServer。NameServer启动后监听端口，等待Broker、Producer以及Consumer连上来
启动Broker。启动之后，会跟所有的NameServer建立并保持一个长连接，定时发送心跳包。心跳包中包含当前Broker信息(ip、port等)、Topic信息以及Borker与Topic的映射关系
创建Topic。创建时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic
Producer发送消息。启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic所在的Broker；然后从队列列表中轮询选择一个队列，与队列所在的Broker建立长连接，进行消息的发送
Consumer消费消息。跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，进行消息的消费

10、RocketMQ是如何实现定时消息的？ （了解）
定时消息是指消息发到Broker后，不能立刻被Consumer消费，要到特定的时间点或者等待特定的时间后才能被消费。 其实定时消息实现原理比较简单，如果一个topic对应的消息在发送端被设置为定时消息，那么会将该消息先存放在topic为SCHEDULE_TOPIC_XXXX的消息队列中，并将原始消息的信息存放在commitLog文件中，由于topic为SCHEDULE_TOPIC_XXXX，所以该消息不会被立即消息，然后通过定时扫描的方式，将到达延迟时间的消息，转换为正确的消息，发送到相应的队列进行消费。

11、说说RocketMQ怎么对文件进行读写的？（了解）
RocketMQ对文件的读写巧妙地利用了操作系统的一些高效文件读写方式——PageCache、顺序读写、零拷贝。
PageCache、顺序读取
在RocketMQ中，ConsumeQueue逻辑消费队列存储的数据较少，并且是顺序读取，在page cache机制的预读取作用下，Consume Queue文件的读性能几乎接近读内存，即使在有消息堆积情况下也不会影响性能。而对于CommitLog消息存储的日志数据文件来说，读取消息内容时候会产生较多的随机访问读取，严重影响性能。如果选择合适的系统IO调度算法，比如设置调度算法为“Deadline”（此时块存储采用SSD的话），随机读的性能也会有所提升。
页缓存（PageCache)是OS对文件的缓存，用于加速对文件的读写。一般来说，程序对文件进行顺序读写的速度几乎接近于内存的读写速度，主要原因就是由于OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache。对于数据的写入，OS会先写入至Cache内，随后通过异步的方式由pdflush内核线程将Cache内的数据刷盘至物理磁盘上。对于数据的读取，如果一次读取文件时出现未命中PageCache的情况，OS从物理磁盘上访问读取文件的同时，会顺序对其他相邻块的数据文件进行预读取。
零拷贝
另外，RocketMQ主要通过MappedByteBuffer对文件进行读写操作。其中，利用了NIO中的FileChannel模型将磁盘上的物理文件直接映射到用户态的内存地址中（这种Mmap的方式减少了传统IO，将磁盘文件数据在操作系统内核地址空间的缓冲区，和用户应用程序地址空间的缓冲区之间来回进行拷贝的性能开销），将对文件的操作转化为直接对内存地址进行操作，从而极大地提高了文件的读写效率（正因为需要使用内存映射机制，故RocketMQ的文件存储都使用定长结构来存储，方便一次将整个文件映射至内存）。
说说什么是零拷贝?
在操作系统中，使用传统的方式，数据需要经历几次拷贝，还要经历用户态/内核态切换。

从磁盘复制数据到内核态内存；
从内核态内存复制到用户态内存；
然后从用户态内存复制到网络驱动的内核态内存；
最后是从网络驱动的内核态内存复制到网卡中进行传输。
所以，可以通过零拷贝的方式，减少用户态与内核态的上下文切换和内存拷贝的次数，用来提升I/O的性能。零拷贝比较常见的实现方式是mmap，这种机制在Java中是通过MappedByteBuffer实现的。

12、RocketMQ消息长轮询了解吗？（了解）
所谓的长轮询，就是Consumer 拉取消息，如果对应的 Queue 如果没有数据，Broker 不会立即返回，而是把 PullReuqest hold起来，等待 queue 有了消息后，或者长轮询阻塞时间到了，再重新处理该 queue 上的所有 PullRequest。

PullMessageProcessor#processRequest
挂起的请求，有一个服务线程会不停地检查，看queue中是否有数据，或者超时。
PullRequestHoldService#run()

1、如何设计一个订单号生成服务
看数据量的大小：在设计订单号生成服务时，需要充分考虑数据量的大小，以确定生成的ID所需的位数。这可以避免位数不足导致存储问题，同时确保足够的位数以防止影响索引检索效率。
不重复、唯一性：订单号必须保证唯一性，否则会出现订单冲突和数据不一致等问题。可采用UUID、Snowflake、数据库生成或者利用Redis等机制，确保订单号的全局唯一性。
考虑高可用：通过多节点部署、负载均衡、健康检查等技术手段，确保服务在面对故障时能够保持可用状态，避免影响其他服务。
易于理解：为了方便排查问题，需要考虑到订单号的格式和组成，可以使用时间戳、随机数、用户ID等信息来拼接订单号。
安全性：不能让别人通过订单号看出公司的经营状况，比如你的订单就是流水号的话，那么别人就可以从订单号推测出你公司的整体运营状况。
2、订单超时自动取消功能如何设计
定时任务：通过定时任务隔一段时间扫表，对于过期超时的订单数据更新状态为已取消。这种方式容易实现；缺点就是定时任务是固定时间间隔的，所以一些订单并不能及时到点的去立马取消，可能过期了一两分钟才被定时任务扫描到；而且这种方式也增加了数据库的压力，当表里数据越来越多之后，扫描的时间也会越来越长。所以这种方式适合对时间要求不高的，数据量也不是很多的业务场景。
DelayQueue延迟队列：DelayQueue是JDK提供的一个无界队列，订单生成以后，设置过期时间放入定义好的DelayQueue，然后创建一个线程，在线程中通过while(true)不断的从DelayQueue中获取过期的数据。这种方式不依赖数据库，也不依赖其他组件，实现也方便；但是DelayQueue是一个无界队列，如果放入的订单数据过多，就会造成OOM。所以这种方式适合数据量比较小的，万一丢失了影响也不大的业务场景。
Redisson：Redisson是一个基于Java的Redis客户端和分布式锁库，它提供的功能中有一个分布式延迟队列RDelayedQueue，是基于zset结构实现的延迟队列，实现类是RedissonDelayedQueue。这种方式使用简单，并且其实现类中大量使用lua脚本保证其原子性，不会有并发重复问题。
MQ延迟消息：RocketMQ 提供了支持延迟消息的功能(RabbitMQ并没有直接支持延迟消息的功能，要结合插件等才行)，延迟消息就是当消息写入到Broker后，不会立刻被消费者消费，需要等待指定的时长后才可被消费处理；在订单创建之后，我们就可以把订单信息作为一条消息投递到rocketmq，并设置延迟时间，等到了时间之后consumer就可以消费到这条消息，然后检查用户是否支付了这个订单，没支付就取消。这种方式可以使代码逻辑清晰，系统之间完全解耦，只需关注生产及消费消息，而且吞吐量极高，最多可以支撑万亿级的数据量；缺点就是引入MQ，要考虑消息丢失，消息积压等问题，会增加系统的复杂度。
MQ的死信队列：因为过了存活时间（TTL）、队列长度超限、被消费者拒绝等原因无法被消费时，就会被投递到死信队列。当队列中没有被消费支付的订单到了指定时间之后，投递到死信队列，然后消费这个死信队列，对死信队列中的订单消息进行取消。
Redis过期监听：Redis提供了过期监听的功能，在redis.conf配置文件中配置notify-keyspace-events Ex开启监听功能，然后在代码中继承KeyspaceEventMessageListener，实现onMessage方法就可以监听过期的数据。我们对订单设置过期时间，然后放入到redis，到了时候后，就消费这个key，检查用户是否支付了。
3、如何设计一个购物车功能
购物车系统的主要功能是在用户选择商品后，在下单之前保存用户的意向商品、数量等信息，以便用户进行统一支付。购物车的操作主要包括加入购物车、查看购物车以及通过购物车下单等。
一般情况下，在存储购物车信息时，并不需要保存商品的所有详细信息，只需记录一个SKU ID，并加上数量、时间等字段即可。商品的库存、价格、介绍等信息可以在渲染购物车时实时查询和计算。
对于未登录用户，购物车信息可以临时缓存在客户端，使用Cookie或LocalStorage等技术进行存储。以下是一个JSON格式的未登录用户购物车存储示例：
{
"cart": [
{
"SKUID": 10086,
"timestamp": 1666513990,
"count": 2
},
{
"SKUID": 10010,
"timestamp": 1666513990,
"count": 10
}
]
}已登录用户的购物车需要使用持久化存储，可以选择数据库或Redis缓存。如果使用数据库，可以创建表格存储user_id、sku_id、count、time_stamp等业务字段。如果使用Redis，可以在未登录用户购物车的基础上添加user_id作为key，如下所示：
{
"KEY": 12343123,
"VALUE": [
{
"SKUID": 10086,
"timestamp": 1666513990,
"count": 2
},
{
"SKUID": 10010,
"timestamp": 1666513990,
"count": 10
}
]
}使用Redis和数据库各有优势：Redis性能更高，响应时间更短，能支撑更多并发请求；而MySQL具有较高的数据可靠性和支持丰富的查询方式和事务机制。
4、如果让你设计一个秒杀系统，怎么设计？
一个秒杀系统面临着多个独特的挑战，设计的时候应该考虑以下问题：
1.高并发瞬时流量：
在处理秒杀场景的高并发瞬时流量时，系统的稳定性和可用性成为关键挑战。通常，我们会在整体架构设计上采取逐层的流量过滤策略，确保系统能够有效处理巨大的请求压力。
首先，从客户端开始，可以在这一层实施一些请求的随机丢弃，以降低服务端的压力。被丢弃的请求可以直接返回失败或系统繁忙的提示，引导用户重试。这种方式可以在离用户更近的地方进行流量过滤。
接下来，通过CDN（内容分发网络）和Nginx进行统一接入，不仅可以实现负载均衡和流量分发，还可以配置黑白名单、IP限流等策略，进行更细粒度的流量过滤。
在服务端，通过Nginx配置的流量过滤和前端的丢弃策略，可以减轻服务端的压力。服务器层面也可以配置各种限流策略，例如基于Sentinel的动态限流，自定义的限流算法等。
此外，针对一些查询操作和写操作，可以使用缓存来提高性能。在缓存方面，本地缓存的响应速度更快，近端缓存效果优于远端缓存，可以有效抵挡部分请求。
由于秒杀业务本身允许一定的失败率，通过层层过滤，我们可以在前端、Nginx、服务器等层次上过滤更多的流量，提升系统的稳定性，确保在高并发情况下仍能提供可用的服务。
2. 热点数据：
秒杀系统常面临热点数据问题，特别是在大家抢购同一商品时，该商品成为热点数据。这带来了高频的查询请求和非常频繁的写请求，尤其是在库存扣减等操作上。
针对热点数据，主要的解决方案包括拆分和缓存。
首先是拆分，即将热点数据分割成多个相对冷门的数据，并通过负载均衡将不同请求分散到不同的数据上，以降低单一数据的请求压力。
其次是利用缓存。通常，对于秒杀业务，可以提前预知哪些数据会成为热点，因此可以提前进行缓存的预热。这不仅包括在Redis等缓存中的预热，还应在本地缓存上执行预热，以避免Redis的热key问题。在处理热点数据时，充分利用缓存可以有效减轻数据库的负担，提高系统的响应速度。
通过拆分和缓存的组合应用，能够有效缓解热点数据带来的高并发压力，提升系统的稳定性和性能。
3. 数据量大：
秒杀系统经常面临高频的下单操作，导致最终产生的订单量巨大，进而带来了查询效率低的问题。
针对这个挑战，有几种可行的解决方案：
加缓存： 在查询订单时可以引入缓存，将常被查询的订单数据缓存在内存中，以提高查询效率。可以使用分布式缓存如Redis等。
使用Elasticsearch（ES）： 当订单数据量庞大时，可以考虑使用Elasticsearch进行存储和检索。ES对于大规模文档的全文搜索和分析非常高效，适用于订单数据的查询。
分库分表： 当单一数据库无法承载巨大的订单数据时，可以考虑采用分库分表的方式，将订单数据分散存储在多个数据库或表中，提高查询性能。
数据归档： 对于历史订单数据，可以实施数据归档策略，将过早的历史数据归档到冷数据存储中，减轻热数据存储的压力。这样可以保证查询性能，同时降低存储成本。
选择适当的方案取决于具体业务需求和系统架构。可能需要综合考虑缓存的实时性、ES的搜索能力、分库分表的扩展性以及数据归档的存储成本等因素。
4. 库存的正确扣减：
在秒杀业务中，由于高频的并发库存扣减操作，提升库存扣减的性能并确保准确性是一项极为重要的任务。稍有不慎可能导致超卖、少卖等严重问题。
为了解决这个问题，可以采取以下策略：
优化数据库事务： 通过合理设置数据库事务隔离级别，减小事务的范围，降低锁竞争，提高并发处理能力。合理使用事务的提交点，确保扣减库存和生成订单等关键操作的原子性。
使用乐观锁： 在数据库层面引入乐观锁机制，通过版本号或时间戳等方式进行标记，减少锁的争用，提高并发性能。乐观锁对于高并发场景有较好的适应性。
分布式锁： 对于分布式系统，可以引入分布式锁，确保同一时刻只有一个请求能够扣减库存。分布式锁可以有效避免并发写入冲突。
异步扣减： 将库存扣减操作异步化，通过消息队列等方式将扣减请求发送到异步处理队列中。这样可以降低同步扣减的压力，提高系统整体吞吐量。
缓存预减： 使用缓存对库存进行预减，减少对数据库的实际扣减操作。当缓存库存为负值时，再进行实际的数据库扣减，避免超卖。
定时任务回补： 针对因各种原因导致未能成功扣减库存的情况，可以设置定时任务进行库存的回补，确保库存的准确性。
以上策略的选择应根据具体业务需求和系统架构来决定。综合考虑事务隔离级别、数据一致性、系统复杂度等因素，可以设计出更高效和稳定的库存扣减方案。
5. 黄牛抢购：
在秒杀业务中，由于商品存在差价，吸引了大量黄牛参与抢购，因此如何识别并阻挡这些黄牛的下单行为显得至关重要。
首先，防刷的核心在于检测可能是黄牛的用户，这涉及到风控领域，通常需要借助算法模型。通过分析用户的IP、设备信息、网络数据、行为模式等，可以推算出可能是黄牛的用户。
一旦识别出潜在的黄牛用户，需要对他们的流量进行防控。这可以通过以下手段实现：
用户ID黑名单： 将识别出的黄牛用户ID加入黑名单中。Nginx和业务系统都可以在流量过滤时检查黑名单，如果用户在黑名单中，直接拒绝请求。
IP地址、设备限流： 对于黄牛用户的IP地址和设备进行限流。例如，限制某个IP地址在一段时间内只能下单几次。这可以利用令牌桶、漏桶等限流算法来实现。
借助限流工具： 利用诸如Nginx、Sentinel、Guava等限流工具，直接在系统层面进行流量控制。这些工具提供了强大的限流功能，能够有效防止过量的请求。
通过综合利用黑名单、限流算法和专门的防刷工具，可以提高系统对黄牛的防控能力，确保秒杀活动的公平性和稳定性。
6. 重复下单：
在秒杀业务中，用户频繁尝试下单支付可能导致重复下单问题，占用额外库存，最终导致少卖的情况。因此，需要采取一些手段来避免重复下单。
首先，基于前述提到的token，可以用于重复下单的检测。通过在同一页面上未刷新的情况下，保持token的一致性，可以利用token进行重复下单的检测，有效避免了此类问题。
此外，在秒杀业务中通常存在限购策略，因此可以结合业务场景，判断用户是否已有在途订单，通过限购方式来防止用户重复下单。
然而，上述过程中可能存在并发情况，导致token检测和订单重复性判断时的并发问题。为了保证下单操作的幂等性，引入锁机制是必要的。
通过引入锁机制，可以确保在并发场景下，同一用户不会重复下单。可以采用分布式锁，数据库乐观锁，或者业务层面的锁机制，以确保下单操作的原子性和幂等性，防止重复扣减库存和生成重复订单。这有助于维护系统的稳定性和数据的准确性。
7. 对普通交易的影响：
秒杀通常作为电商网站的一个功能，往往与其他业务一同部署，包括服务器、缓存和数据库等资源。为避免秒杀业务对普通交易造成过大的影响，需要考虑隔离策略。
隔离可以采用逻辑隔离和物理隔离两种方式，具体实施视业务需求而定。
物理隔离： 物理隔离是指将秒杀业务的前后端服务以及数据存储完全分离。这样可以确保秒杀活动对其他业务的影响最小化。前后端服务可以单独部署，甚至使用不同的服务器集群，以确保资源独立。
逻辑隔离： 在应用层面进行逻辑隔离，即通过对数据进行标记或打标签的方式来区分秒杀订单和普通订单。例如，在订单和商品数据上添加标记，明确标识出哪些是秒杀订单。这样在后续的查询和数据分析中，可以更方便地区分和处理不同类型的订单。
综合考虑业务场景和系统复杂度，可以选择适当的隔离策略。物理隔离更彻底，但成本和复杂度也更高。逻辑隔离则相对灵活，能够在业务层面实现隔离效果，同时降低了部署和维护的难度。
5、应用程序中存在包冲突的情况下，怎么发现和解决
包冲突是指在应用程序中引入的不同版本的库或依赖之间存在冲突，可能导致编译错误、运行时异常或其他不稳定行为。解决包冲突通常需要以下步骤：
诊断冲突： 确定哪些包发生了冲突，以及冲突的具体原因。可以通过查看编译日志、运行时异常信息或使用工具来分析依赖关系。
查看依赖关系： 使用构建工具或依赖管理工具查看项目的依赖关系。对于Java项目，可以查看Maven的依赖配置文件。了解每个依赖项的版本以及它们之间的关系。
升级或降级依赖版本： 如果发现包冲突是由于不同依赖项使用了相同库的不同版本而引起的，可以考虑升级或降级相关依赖项的版本，以便它们使用相同的库版本。
排除依赖项： 对于某些依赖项，可以使用排除（exclusion）机制来排除特定的传递性依赖项。这样可以防止冲突的库被引入。
在Maven中，可以使用 ＜exclusions＞ 元素：
＜dependency＞
＜groupId＞example＜/groupId＞
＜artifactId＞example-artifact＜/artifactId＞
＜version＞1.0＜/version＞
＜exclusions＞
＜exclusion＞
＜groupId＞conflicting-group＜/groupId＞
＜artifactId＞conflicting-artifact＜/artifactId＞
＜/exclusion＞
＜/exclusions＞
＜/dependency＞使用类加载器隔离： 对于较为复杂的场景，可以考虑使用类加载器隔离机制，将不同版本的库加载到不同的类加载器中。这样可以在同一应用中使用不同版本的库而不会发生冲突。但需要注意，类加载器隔离可能引入新的问题，需要谨慎使用。
升级项目依赖： 如果有可能，可以考虑升级项目的所有依赖项到最新版本，以确保使用的库都是相对较新的版本，减少冲突可能性。
使用依赖锁定工具： 一些工具如Maven Enforcer Plugin可以帮助检测项目中的依赖冲突，提供更全面的依赖关系报告。
6、跨节点join查询如何实现
在分布式系统中，跨节点的Join查询是一个具有挑战性的问题，因为传统的关系数据库系统通常设计为在单一节点上执行Join操作。在分布式环境下，有一些常见的解决方案：
数据复制： 将涉及到Join操作的表数据在分布式环境中的每个节点上都复制一份。这样，每个节点可以在本地执行Join操作而无需跨节点通信。这种方法虽然简单，但会导致数据冗余和一致性的问题。
分布式Join算法： 开发专门的分布式Join算法，使得在分布式环境下也能高效执行Join操作。例如，MapReduce框架就提供了一些分布式Join的实现。这需要对数据进行划分和分布式计算。
使用分布式数据库： 选择支持分布式Join的分布式数据库系统。一些分布式数据库提供了内建的分布式Join支持，可以在分布式环境中高效地执行Join查询。
分片和合并： 将Join操作分解为可在每个节点上执行的部分，然后在一个中心节点上合并结果。这种方式需要设计合适的数据分片策略和结果合并机制。
数据缓存： 在每个节点上缓存可能用于Join的数据片段，以减少跨节点通信的需求。这需要根据查询模式预先缓存可能用到的数据。
消息传递： 使用消息传递机制，将涉及Join的查询分解为子查询，分发到各个节点执行，然后将结果进行合并。这需要有效的通信机制和任务协调。
全局索引： 在所有节点上建立全局索引，以加速Join查询。这需要维护一致的全局索引，可能带来额外的维护成本。
7、Excel中百万级数据怎么导入到数据库
在处理百万级数据从Excel读取并插入到数据库的场景中，涉及到多方面的问题，需要综合考虑性能、内存占用、错误处理等因素。以下是一个可能的解决方案：
内存溢出问题
使用流式读取方式，分批处理Excel数据。选择EasyExcel作为处理工具，它能够逐行读取数据而不将整个Excel加载到内存中，避免内存溢出的问题。
性能问题
考虑多线程处理，使用线程池同时读取不同的sheet，以提升并发性能。对于数据插入操作，借助多线程和数据库的批量插入功能，进一步提高性能。
错误处理
数据检查： 在读取和插入之前进行数据检查，处理数据格式错误、不一致等问题。
异常处理： 在插入过程中，对异常进行处理。采用自动重试机制，一定次数内尝试重新插入。记录日志以便后续分析。
数据重复处理： 设置Excel中某几个字段为数据库唯一性约束，处理数据重复问题。可以选择覆盖、跳过或报错，根据业务需求选择合适的方式。
整体方案
使用EasyExcel逐行读取Excel数据，通过多线程和线程池同时处理不同sheet的数据。
数据分批插入，设置一个批次大小，当达到批次大小时执行一次批量插入操作。
利用线程安全的队列（如ConcurrentLinkedQueue）暂存内存中的数据，确保并发安全性。
通过这种方案，能够在相对较短的时间内处理百万级数据的读取和插入，同时保证了内存的有效利用和错误处理的可靠性。具体的实现可以基于以上思路，结合实际项目需求和技术栈进行调整。
8、缓存预热怎么实现
在系统中进行缓存预热是为了提高系统性能和响应速度的一种策略。常见的缓存预热方案包括：

1. 启动过程中预热
   一种常见的实现方式是在系统启动时进行缓存预热，特别适用于本地缓存。在Spring应用程序启动时，可以通过监听应用启动事件或在初始化阶段，将需要缓存的数据加载到缓存中。Spring提供了多个事件和扩展点，如ApplicationReadyEvent、CommandLineRunner、InitializingBean、@PostConstruct等，可用于执行预热逻辑。

2. 定时任务
   定时任务是在系统运行过程中通过设定的时间间隔更新缓存，以确保缓存中的数据保持最新。在Spring中，可以使用@Scheduled注解轻松实现定时任务，适用于需要动态更新的情况。

3. 用时加载
   基于用户的查询模式和业务需求，动态地在用户请求到达时将数据加载到缓存中。这种方式更加灵活，可以根据实际需求选择性地预热缓存。示例代码如下：
   public Data fetchData(String key) {
   // 先检查缓存中是否存在数据
   Data cachedData = cache.get(key);

   if (cachedData == null) {
   // 如果缓存中不存在，根据业务需求加载数据到缓存中
   // ...
   }

   return cachedData;
   }4. 缓存加载器
   某些缓存框架提供了缓存加载器的机制，当缓存中不存在数据时，自动调用加载器加载数据到缓存中。例如，在Caffeine中可以使用LoadingCache实现，简化了缓存预热的逻辑。示例代码如下：
   import com.github.benmanes.caffeine.cache.Caffeine;
   import com.github.benmanes.caffeine.cache.LoadingCache;
   import org.springframework.stereotype.Service;

import java.util.concurrent.TimeUnit;

@Service
public class MyCacheService {

private final LoadingCache＜String, String＞ cache;

public MyCacheService() {
    this.cache = Caffeine.newBuilder()
            .refreshAfterWrite(1, TimeUnit.MINUTES)  // 配置自动刷新，1分钟刷新一次
            .build(key -＞ loadDataFromSource(key));  // 使用加载器加载数据
}

public String getValue(String key) {
    return cache.get(key);
}

private String loadDataFromSource(String key) {
    // 从数据源加载数据的逻辑
    // ...
}

}以上方案可根据具体业务需求和技术栈进行选择和调整，以达到最佳性能和可维护性。
9、表数据量大的时候只能分库分表？
当MySQL中的单表数据量庞大时，考虑分库分表通常是为了提升数据库吞吐量和查询效率。然而，分库分表方案的实现较为复杂，且可能引发一系列问题，如跨库事务、分页查询等。在采取分库分表之前，应优先考虑以下方案：
数据库优化： 通过优化数据库结构、使用合适的索引、调整SQL语句等手段，可以有效提升查询性能。在2000万数据量级别，合理使用索引和进行表结构设计优化能够显著改善数据库性能。
缓存： 减轻数据库压力可以通过缓存实现。在近端引入本地缓存或分布式缓存，能够迅速返回结果并减轻数据库负担，提高系统性能。
分区： 数据分区可以减小单个表的物理存储空间，将数据分散存储在不同的表或文件中，以降低单表的数据量，从而提高查询性能。
数据归档： 定期清理不再需要或不再活跃的数据，将其归档到辅助存储中（如历史表、离线数仓），可以减少数据量，进而提升数据库效率。
分布式数据库： 考虑采用分布式数据库系统，充分利用多个节点分散数据，提高系统性能和容量。尽管分布式数据库成本较高，但相较于分库分表的改造而言，收益更为显著。
这些方案在实施时需要根据具体业务场景和需求进行综合考虑，选择最适合的优化方案，以达到性能提升的效果。
10、线上发现一个接口响应很慢，怎么排查问题
监控工具：可以使用性能监控工具来实时监控接口的响应时间、吞吐量和错误率等指标。常见的监控工具：Arthas、Prometheus、Grafana、AppDynamics等。
日志分析：查看接口的日志文件，关注接口的执行时间、请求参数和响应结果等消息。同构分析可以找到执行时间较长的接口，以及可能导致慢接口的原因。
接口性能测试：通过模拟多用户并发请求，观察接口的响应时间和吞吐量等指标，找出慢响应的接口。常见的性能测试工具：JMeter、LoadRunner等。
数据库查询分析：如果接口涉及数据库查询，通过数据库查询分析工具（如EXPLAIN语句）来检查查询执行计划，确保数据库查询效率。
代码剖析：对接口代码进行剖析，了解代码中的性能瓶颈和耗时操作，通过剖析结果找到影响性能的代码段，进行优化，常见的剖析工具：Java Profiler、VisualVM等
11、MQ里面数据到达1000万的时候，怎么尽快消费掉
增加消费者数量: 消息堆积了，消费不过来了，那就把消费者的数量增加一下，让更多的实例来消费这些消息。
提升消费者消费速度：消费者消费的慢可能是消息堆积的主要原因，想办法提升消费速度，比如引入线程池本地消息存储后即返回成功后续再慢慢消费等。
降低生产者的生产速度：如果生产者可控的话，可以让生产者生成消息的速度慢一点。
清理过期消息：有一些过期消息、或者一直无法成功的消息，在业务做评估之后，如果无影响或者影响不大其实是可以清理的。
调整 RocketMQ 的配置参数: RocketMQ 提供了很多可配置的参数，例如消息消费模式、消息拉取间隔时间等，可以根据实际情况来调整这些参数，从而优化消息消费的效率。
增加Topic队列数: 如果一个 Topic 的队列数比较少，那么就容易出现消息堆积的情况。可以通过增加队列数来提高消息的处理并发度，从而减少消息堆积。
12、涉及到订单超卖问题怎么解决
订单超卖：就是当有两个并发线程同时查询库存商品，这时数据库中商品库存就剩1个，所以两个线程得到的库存数量都是1，然后经过库存校验之后分别开始进行库存扣减，最终导致库存被扣减成负数。
悲观锁：在更新库存的时候使用数据库的锁机制，如SELECT ... FOR UPDATE，确保同一时间只有一个线程能够操作库存。悲观锁会在操作数据之前先获取锁，其他事务需要等待锁释放后才能执行操作，但会增加数据库的负担和死锁的风险。
乐观锁：通过版本号或时间戳等机制，在更新库存时进行比较，如果发现库存不足，则拒绝更新。这样可以保证只有一个线程能够成功更新库存，其他线程需要进行重试或处理失败情况。但需要处理并发冲突的情况。
限流：对订单的创建进行限流，防止短时间内大量订单的涌入，从而减小并发冲突的可能性。可以使用令牌桶算法或漏桶算法来实现限流；
限制同一IP在一定时间内只能发送一个请求。可以通过在网关中自定义全局过滤器来实现IP限流；
限制接口每秒只接受一定数量的请求。可以使用Sentinel的限流功能；
库存预留：在用户下单时，先检查库存是否足够，并将一部分库存标记为已预留状态。在订单支付完成后再确认扣减库存。
缓存：利用缓存的原子操作特性来扣减库存，可以使用Redis的incrby命令来实现库存的扣减。
消息队列：使用消息队列，将订单的创建和库存的更新分开处理。订单先进入消息队列，然后由后台异步任务进行处理，保证订单和库存的更新是顺序执行的。这样可以降低竞争条件的发生。

1、synchronized的用法

1. 修饰实例方法
   当synchronized用于修饰一个实例方法时，该方法被称为同步方法。这意味着在同一时刻，只有一个线程可以进入该方法的代码块。这种同步是基于对象的实例锁，即每个对象都有一个锁，当线程进入一个对象的同步方法时，它必须先获得该对象的锁。如果另一个线程已经持有该对象的锁，则该线程必须等待，直到锁被释放。
   public synchronized void syncMethod() {
   // method body
   }2. 修饰静态方法
   修饰静态方法时，同步是基于类对象（Class对象）的锁。这意味着所有实例共享同一把锁。当一个线程进入一个静态的同步方法时，它获得的是该类的锁。如果其他线程已经持有该类的锁，则新来的线程必须等待。
   public static synchronized void staticSyncMethod() {
   // method body
   }3. 修饰代码块
   当synchronized用于修饰一个代码块时，它允许你指定一个锁对象。这种方式提供了更细粒度的控制，因为它允许你只同步访问特定资源和数据部分的代码。代码块中的代码在执行时必须持有指定的锁对象。
   public void someMethod() {
   Object lock = new Object();
   synchronized(lock) {
   // code block
   }
   }2、锁升级
   （1）、内存布局 （对象的内存布局）

在 Java 中，每个对象的内存布局是由 Java 虚拟机（JVM）的具体实现决定的，例如 Oracle HotSpot JVM。这里，我们可以讨论 HotSpot JVM 中普通（非数组）对象的典型内存布局。对象的内存布局通常包括三部分：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

1. 对象头（Object Header）
   对象头包含了对象自身运行时的一些必要信息，包括两部分：标记字（Mark Word）和类型指针。
   Mark Word：这部分通常占用 8 字节，用于存储对象自身的运行时数据，如哈希码、锁信息（锁状态标记、线程持有的锁等）、垃圾收集信息（如年龄、是否存活等）。
   Class Pointer：这部分通常也占用 4 字节（默认情况下)

2. 实例数据（Instance Data）
   实例数据部分占用的字节数取决于对象的具体字段。Java 数据类型的字节如下：
   boolean 和 byte：1 字节
   char 和 short：2 字节
   int 和 float：4 字节
   long 和 double：8 字节
   引用类型（如对象引用）：在 64 位 JVM 中通常是 4 字节（使用压缩指针时）或 8 字节。
   字段的排列可能会由 JVM 进行优化，以减少由于内存对齐引起的空间浪费。

3. 对齐填充（Padding）
   为了使对象的总大小是 8 字节的倍数（这是大多数现代计算机系统内存寻址的最小单位），JVM 可能会在实例数据之后添加一些填充字节。这样做是为了确保内存对齐，有助于提高 CPU 缓存的效率。
   示例
   考虑一个简单的 Java 对象：
   public class Example {
   int a; // 4 字节
   boolean b; // 1 字节
   }在这个例子中，对象的内存布局可能如下：
   对象头：12 字节（压缩类指针）或 16 字节（非压缩）
   实例数据：int 4 字节 + boolean 1 字节 = 5 字节
   对齐填充：为了使总大小为 8 字节的倍数，可能需要添加 3 字节的填充。
   这样，总的大小可能是 20 字节（12+5+3，使用压缩指针的情况）或 24 字节（16+5+3，未使用压缩指针）。
   Java 示例：简单的 Person 类
   考虑下面的 Java 类 Person，它有两个字段：name 和 age。此示例将帮助我们理解类型指针在不涉及继承的情况下如何工作。
   public class Person {
   private String name;
   private int age;

   public Person(String name, int age) {
   this.name = name;
   this.age = age;
   }

   public void printInfo() {
   System.out.println("Name: " + name + ", Age: " + age);
   }

   public static void main(String[] args) {
   Person person = new Person("John Doe", 30);
   person.printInfo(); // 输出: Name: John Doe, Age: 30
   }
   }类型指针的作用
   当我们创建 Person 类的一个实例时：
   对象创建：JVM 在堆内存中为 Person 对象分配空间。这块空间包括对象头、实例数据（name 和 age），以及可能的一些填充字节来满足内存对齐要求。
   对象头：对象头包含了几个重要的组成部分，其中关键的部分是类型指针。
   类型指针：这个指针指向 Person 类的元数据。该元数据包含了有关 Person 类的各种信息，如字段布局、方法表、类加载器信息等。
   使用类型指针：
   当调用 person.printInfo() 方法时，即使这个例子没有显示继承和多态，类型指针仍然起到关键作用。JVM 使用类型指针查找到 Person 类的元数据，进而定位到 printInfo() 方法的实际代码。
   这个查找过程确保了即使在类的代码在内存中移动或通过热部署改变时，方法调用也总是正确的，因为类型指针总是指向当前有效的类定义。
   （2）、markword 里面具体存的是什么东西

3、synchronized早期为什么叫做重量级锁
在JDK早期 synchronized被称之为重量级锁，是因为我的JVM也是在用户态，有线程向jvm申请锁的时候，那我们JVM需要向操作系统申请锁，那这个过程涉及到从用户态切换到内核态，再从内核态切换到用户态，所以称synchronized为重量级锁。
比较底层的实现（操作系统层面）
当一个 Java 线程尝试进入一个由 synchronized 关键字保护的同步块或方法时，它首先需要获得锁。如果锁已被另一个线程持有，尝试获取锁的线程需要等待。在 Java 的早期实现中，这种等待是通过操作系统的互斥量（Mutex）实现的。这意味着以下几个步骤：
锁请求：当线程无法立即获取锁时，JVM 会在用户态下发出一个系统调用，请求操作系统的互斥量。
状态切换：执行系统调用（如请求互斥量）涉及从用户态切换到内核态，因为互斥量的管理是在操作系统内核中处理的。
等待和唤醒：线程在内核控制的等待队列中阻塞，直到锁变为可用。当锁释放时，操作系统负责唤醒等待的线程，这通常再次涉及从内核态回到用户态的切换。
4、锁升级过程
随着 Java 平台的发展，特别是从 JDK 6 开始，对 synchronized 锁的实现进行了优化。引入了如轻量级锁和偏向锁等技术，使得许多锁操作现在可以完全在用户态下完成，避免了频繁的模式切换。当锁竞争不激烈时，这些优化可以显著减少锁的开销。
在Java中，synchronized关键字实现的锁机制涉及一个从无锁状态到偏向锁、轻量级锁和最终可能的重量级锁的升级过程。这个机制极大地提高了锁的效率，尤其是在不同的并发场景中。下面，我们将更详细地讨论每个锁状态的内部工作机制和对象头中的标记位。
无锁状态
锁状态: 当没有线程尝试获取对象的锁时，对象处于无锁状态。无锁并不意味着对象不能被锁定，而是表明当前没有锁定行为。
标记位: 在无锁状态下，对象头的标记位通常设置为01（在开启偏向锁的情况下），这表示这个对象可以进入偏向锁状态。
偏向锁
偏向锁是为了优化单个线程多次获取同一个锁的情况。当第一次有线程获取锁时，JVM会将对象头标记为偏向这个线程，以后该线程进入和退出同步块时不需要进行全面的同步。
锁状态: 对象头偏向第一个获得它的线程。
标记位: 对象头的标记位设置为偏向锁模式，其中包括偏向线程的ID。状态位是01，偏向标志位设置为1，后面跟着偏向的线程ID。
轻量级锁
当另一个线程尝试获取已经偏向某个线程的锁时，偏向锁会升级为轻量级锁。轻量级锁的工作原理是在每个线程的栈帧中创建一个锁记录（Lock Record），它包含了锁对象指针。
锁状态: 当锁对象已被线程锁定，但没有其他线程争用它时，使用轻量级锁。
标记位: 轻量级锁的状态位为00，锁指针指向线程栈上的锁记录。
重量级锁
当轻量级锁的自旋锁尝试失败，即有多个线程竞争同一个锁时，轻量级锁会升级为重量级锁。这时，JVM会在操作系统层面挂起其他试图获取这个锁的线程。
锁状态: 涉及操作系统帮助管理线程阻塞和唤醒的重量级锁。
标记位: 重量级锁的状态位通常为10，对象头的锁指针指向一个监视器对象（Monitor），该对象包含了锁的所有者、等待锁的线程列表等信息。
补充内容：
在Java中，轻量级锁升级到重量级锁的自旋次数并没有一个固定的标准，因为这个值可以根据JVM的具体实现和运行时的调优参数而变化。不过，一般来说，HotSpot JVM中有几个因素决定了自旋的次数：
自旋次数的默认设置：在早期的HotSpot JVM版本中，自旋的默认次数大约是10次。这意味着如果一个线程尝试获取锁但失败，并且通过自旋的方式进行了约10次重试仍旧无法成功，那么锁将可能被升级为重量级锁。
自适应自旋锁：从Java 6开始，HotSpot JVM引入了自适应自旋锁。在这种机制下，自旋的次数不是固定的，而是由JVM在运行时根据之前在同一锁上的自旋行为和锁的竞争情况动态调整的。如果在某个锁上自旋成功率高，JVM可能会增加自旋的次数；反之，如果成功率低，则减少自旋次数。
JVM调优参数：在HotSpot JVM中，可以通过一些启动参数来调整自旋的行为，例如-XX:PreBlockSpin参数在某些版本的JVM中用于设置线程在阻塞前进行自旋的次数。
synchronized在java代码层面表示
package com.javatiaozao;

public class Main {
public static void main(String[] args) {
Object o = new Object();
synchronized (o) {
System.out.println("我已经上锁了");
}
System.out.println("Hello world!");
}
}synchronized在JVM汇编层面表示
0 new #2 ＜java/lang/Object＞
3 dup
4 invokespecial #1 ＜java/lang/Object.＜init＞ : ()V＞
7 astore_1
8 aload_1
9 dup
10 astore_2
11 monitorenter
12 getstatic #3 ＜java/lang/System.out : Ljava/io/PrintStream;＞
15 ldc #4 ＜我已经上锁了＞
17 invokevirtual #5 ＜java/io/PrintStream.println : (Ljava/lang/String;)V＞
20 aload_2
21 monitorexit
22 goto 30 (+8)
25 astore_3
26 aload_2
27 monitorexit
28 aload_3
29 athrow
30 getstatic #3 ＜java/lang/System.out : Ljava/io/PrintStream;＞
33 ldc #6 ＜Hello world!＞
35 invokevirtual #5 ＜java/io/PrintStream.println : (Ljava/lang/String;)V＞
38 return

1、SpringBean的作用域
参考回答：
singleton：这是Spring框架的默认作用域。Spring IoC容器只会创建该Bean的唯一实例。所有对该Bean的请求都将返回同一个实例。这个Bean是全局共享的，适用于无状态的Bean或者需要在多个组件之间共享数据的情况。
prototype：每次对该作用域下的Bean的请求都会创建新的实例。获取Bean（即通过applicationContext.getBean等方法获取）及装配Bean（即通过@Autowired注入）都是新的对象实例。没有共享状态，适用于有状态的Bean或者需要频繁创建新实例的情况。
request：每次HTTP请求都会创建一个新的Bean实例。每个请求的Bean实例对于该请求是唯一的。这个作用域仅在基于Web的Spring ApplicationContext中有效。适用于处理HTTP请求的控制器或服务。
session：在一个HTTP会话（Session）中，定义一个Bean实例。对于同一用户的所有请求，都将使用相同的Bean实例。这个作用域也仅在基于Web的Spring ApplicationContext中有效，适用于保存用户特定的数据或状态。
global session：在整个应用程序的全局会话中创建一个新的Bean实例。这个作用域主要用于在Portlet环境中定义Bean，因为Portlet规范定义了全局会话的概念，而普通的Web应用（只包含Servlet）中并没有这个概念。在普通的Web应用中，global session作用域等同于session作用域。
2、SpringBean的生命周期
参考回答：
实例化：当Spring IoC容器接收到对某个Bean的请求时，IoC容器会先通过反射机制实例化该Bean。这个阶段完成了BeanFactoryPostProcessor的操作（如果有的话）。
属性赋值：Spring IoC容器在创建Bean的过程中，会将Bean在XML文件中配置的属性值和BeanDefinition中的属性值设置到Bean中。这个过程也称为依赖注入（DI），可以通过构造方法注入、Setter方法注入等方式完成。
Bean后处理器（BeanPostProcessor）处理：在Bean的实例化和属性赋值之后，Spring会调用BeanPostProcessor的postProcessBeforeInitialization方法，对Bean进行进一步的处理。这是一个可选的步骤，开发者可以通过实现BeanPostProcessor接口并覆盖相应的方法来定义自己的处理逻辑。
初始化：如果Bean在容器中配置了init-method，那么这个方法将会被调用，完成Bean的初始化操作。此外，如果Bean实现了InitializingBean接口，那么Spring会调用其afterPropertiesSet方法进行初始化。这也是一个可选的步骤，但通常用于在Bean的所有属性设置完毕后执行一些初始化操作。
实例化后处理：在Bean完成初始化之后，Spring会再次调用BeanPostProcessor的postProcessAfterInitialization方法，对Bean进行最后的处理。这也是一个可选的步骤，开发者可以在这里添加一些额外的逻辑，例如对Bean进行代理等。
使用：此时Bean已经准备就绪，可以被应用程序使用了。Spring容器会管理Bean的生命周期，并在需要的时候将其提供给应用程序。
销毁：当Spring容器关闭时，它会调用所有实现了DisposableBean接口的Bean的destroy方法，并触发在XML配置文件中定义的destroy-method。这是Bean生命周期的最后阶段，用于释放Bean占用的资源。
3、Spring AOP原理
参考回答：
Spring AOP（Aspect Oriented Programming，面向切面编程）的原理主要基于动态代理模式，用于在不修改原有业务代码的前提下，为多个目标对象统一管理并增加额外功能。其核心概念包括切面（Aspect）、连接点（Join Point）、通知（Advice）等。
切面（Aspect）：切面是织入到目标类中的功能代码，对于Java来说可以是方法、构造器或者类的特定点上的代码。切面可以包括前置通知、后置通知、环绕通知、异常通知和最终通知等，具体可以根据业务需求自定义实现。
连接点（Join Point）：连接点表示切面将会被织入到目标对象的哪个位置，对于Java来说通常是某个方法的执行点或者某个构造器的创建点。
通知（Advice）：通知包括各种类型的切面代码，如前置通知、后置通知、环绕通知、异常通知和最终通知等。这些通知会在连接点执行时被触发。
Spring AOP以动态代理技术为主要方式进行织入。具体来说，当目标对象的方法被调用时，Spring AOP会检查该方法是否是一个连接点。如果是，则会在方法执行前后（或者方法执行过程中）织入相应的通知代码。这些通知代码可以在不修改原有业务代码的情况下，为目标对象增加额外的功能。
4、Spring事务传播机制
参考回答：
REQUIRED（默认）：
如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。
SUPPORTS：
如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。
MANDATORY：
如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。
REQUIRES_NEW：
创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说，无论外部方法是否开启事务，REQUIRES_NEW 修饰的内部方法都会新开启自己的事务，且开启的事务相互独立，互不干扰。
NOT_SUPPORTED：
以非事务方式运行，如果当前存在事务，则把当前事务挂起。
NEVER：
以非事务方式运行，如果当前存在事务，则抛出异常。
NESTED：
如果当前存在事务，则在嵌套事务内执行。嵌套事务是独立的事务，但它可以依赖于外部事务的提交或回滚。如果外部事务提交，则嵌套事务也会提交；如果外部事务回滚，则嵌套事务可以选择性地回滚（这取决于它自己的状态）。
5、什么是Spring的循环依赖问题？（了解）
参考回答：
Spring的循环依赖问题是指在Spring容器中，两个或多个Bean之间相互依赖，形成了一个循环引用的情况。具体来说，当一个Bean A依赖于另一个Bean B，而Bean B又依赖于Bean A时，就可能出现循环依赖的问题。
6、什么是spring三级缓存以及如何解决循环依赖（重要）
参考回答：
一级缓存（singletonObjects）：
也称为“单例池”，用于存储所有单例bean的实例对象。
当应用程序需要某个bean时，Spring首先会在一级缓存中查找，如果找到则直接返回该bean的实例。
二级缓存（earlySingletonObjects）：
存放早期暴露出来的bean对象，即实例化以后但属性还未填充的bean对象。
二级缓存在解决循环依赖中只是整个三级缓存机制的一部分，单独依赖二级缓存无法完全解决循环依赖问题。当A bean依赖于B bean，而B bean又依赖于A bean时，Spring可以在创建A bean的过程中将其提前放入二级缓存，以供B bean在实例化后但未填充属性前引用。
三级缓存（singletonFactories）：
也称为“单例工厂池”，用于存储用于创建单例bean的ObjectFactory。
在创建单例bean时，如果发现该bean依赖于其他的bean，则需要先创建该依赖的bean实例。此时，Spring会将用于创建该依赖的ObjectFactory保存到三级缓存中。当依赖的bean创建完成后，Spring会使用这个ObjectFactory来生成最终的bean实例，并将其放入一级缓存中。
通过三级缓存机制，Spring可以更加高效地管理bean的创建和引用过程，特别是在处理循环依赖和懒加载等场景时。此外，缓存机制还可以减少对数据库等持久层资源的访问次数，提高系统的资源利用率和稳定性。
详细内容请看：Srping 一级、spring二级、三级缓存是如何解决循环依赖的
6、spring事务失效的原因？
参考回答：
事务注解添加在非public方法上：Spring事务管理是基于AOP（面向切面编程）实现的，而AOP对于JDK动态代理或CGLib动态代理只会代理public方法。因此，如果@Transaction注解添加在非public方法上，事务将不会生效。
类没有被Spring管理：Spring事务是由AOP机制实现的，AOP机制的本质就是动态代理。从Spring IOC容器获取bean时，Spring会为目标类创建代理，从而支持事务。如果类没有被Spring容器管理（例如，没有添加@Service、@Component等注解），则Spring无法为目标类创建代理，事务也会失效。
异常被捕获且未正确处理：默认情况下，Spring只有在方法抛出运行时异常或者错误时才会回滚事务。如果事务方法内部抛出了异常，但该异常被catch语句捕获且没有重新抛出，或者捕获的异常类型不是运行时异常，那么事务将不会回滚。
事务属性设置不当：如果在Spring的事务管理中，事务的传播特性（propagation）或回滚规则（rollbackFor）设置不当，也可能导致事务失效。例如，如果在一个支持当前事务的方法中调用了需要新事务的方法，并且后者方法抛出了异常，但异常并未被Spring识别为需要回滚事务的异常，那么后者的事务将不会回滚。
数据库配置问题：如果数据库配置不支持事务（例如，使用了不支持事务的数据库引擎），或者数据库本身就是不支持事务的，那么Spring事务也会失效。
调用同一个类中的方法：在Spring中，如果一个事务方法内部调用了同一个类中的另一个方法，而这个方法没有被Spring代理（即没有被标记为@Transactional），那么事务将不会生效。这是因为Spring是通过代理模式来管理事务的，只有在代理对象上调用方法时，事务才会生效。
事务嵌套使用不当：在一个已经开启了事务的方法中再次开启事务，对于Spring的PROPAGATION_REQUIRED模式（默认模式），它只会用原来的事务，这可能导致预期之外的行为。
7、spring bean是否为线程安全的？
参考回答：
Spring容器本身并没有提供Bean的线程安全策略，所以可以说Spring容器中的Bean本身不具备线程安全的特性，但是具体情况还是要结合Bean的作用域来讨论。对于prototype作用域的Bean，每次都创建一个新对象，也就是线程之间不存在Bean共享，因此不会有线程安全问题。对于singleton作用域的Bean，所有的线程都共享一个单例实例的Bean，因此是存在线程安全问题的。
8、spring中用到的设计模式？
参考回答：
工厂模式（Factory Pattern）：
Spring使用工厂模式通过BeanFactory、ApplicationContext等接口创建并管理对象实例。这种方式将对象的创建与使用解耦，使得程序更加灵活和可扩展。
单例模式（Singleton Pattern）：
Spring中的Bean默认都是单例的，即在整个Spring IoC容器中，每个Bean只会有一个实例。这通过Bean的scope属性进行控制，当scope为singleton时，即表示使用单例模式。
代理模式（Proxy Pattern）：
在AOP（面向切面编程）和remoting中被广泛使用。Spring AOP的实现基于动态代理模式，可以在运行时动态地将代码切入到类的指定方法、指定位置上。
模板方法模式（Template Method Pattern）：
解决代码重复问题。Spring中例如JdbcTemplate就是模板方法模式的体现，它封装了数据访问的底层操作，定义了数据访问的骨架，使得开发者可以只关注自己的业务SQL。
前端控制器模式（Front Controller Pattern）：
Spring MVC中的DispatcherServlet就是前端控制器模式的实现，它负责接收请求，并根据请求信息调用相应的处理器（Controller）进行处理。
依赖注入模式（Dependency Injection Pattern）：
贯穿于BeanFactory和ApplicationContext接口的核心理念。通过依赖注入，Spring可以在运行时动态地将一个对象所需要的外部依赖注入到该对象中，从而降低了代码的耦合度。
装饰器模式（Decorator Pattern）：
在Spring中，BeanWrapper是一个很好的装饰器模式的例子。它允许你在运行时动态地给一个对象添加一些额外的职责。
委派模式（Delegation Pattern）：
在Spring MVC中，DispatcherServlet就是一个典型的委派模式的例子。它接收请求，但并不处理请求，而是将请求委派给相应的控制器进行处理。
策略模式（Strategy Pattern）：
在Spring中，HandlerMapping接口的实现类就使用了策略模式。它定义了一个处理请求的接口，具体的处理策略由实现类来完成。
适配器模式（Adapter Pattern）：
在Spring MVC中，HandlerAdapter接口的实现类就使用了适配器模式。它将不同的处理器（Controller）适配成统一的接口，使得DispatcherServlet可以统一调用。
观察者模式（Observer Pattern）：
在Spring的事件驱动模型中，使用了观察者模式。当某个事件发生时，会通知所有注册的观察者（Listener）进行处理。
能说一部分就行了
9、Spring IOC
参考回答：
Spring IoC（Inversion of Control，控制反转）是Spring框架的核心特性之一。它的基本思想是将对象的创建和管理过程从应用程序代码中抽离出来，由Spring容器负责创建和管理对象之间的依赖关系。通过这种方式，应用程序代码不再需要直接创建和管理对象，而是向Spring容器发出请求，由容器负责创建和返回所需的对象。
Spring IoC的主要优点包括：
降低耦合性：通过IoC容器来管理对象之间的依赖关系，使得系统更加模块化、可测试和易于扩展。
提高灵活性和可维护性：由于对象的创建和管理由Spring容器负责，因此可以更加灵活地配置和修改对象的行为。同时，由于代码不再包含对象的创建和管理逻辑，因此可以更加专注于业务逻辑的实现，提高代码的可维护性。
支持多种配置方式：Spring IoC支持多种配置方式，包括XML配置、注解配置和Java配置等。这些配置方式可以根据项目的实际需求进行灵活选择和使用。
在实现Spring IoC时，有三种主要的方式：
使用XML实现Spring IoC：通过编写XML配置文件来定义和配置Bean，将配置信息集中在一个XML文件中进行管理。
使用注解方式实现Spring IoC：通过在类和方法上添加注解来定义和配置Bean，使得配置更加简洁、直观，并且减少了对XML文件的依赖。
使用JavaConfig实现Spring IoC：通过编写Java配置类来定义和配置Bean，将配置信息集中在一个Java类中，提供了一种更加面向对象和类型安全的配置方式。
10、spring AOP在项目中的应用场景？
参考回答：
日志记录：在系统中记录日志是非常重要的，可以使用AOP来实现日志记录的功能。通过在方法执行前、执行后或异常抛出时记录日志，可以方便地跟踪系统的运行情况和问题排查。
事务管理：在数据库操作或其他需要事务管理的操作中，使用AOP可以将事务管理的逻辑与业务逻辑分离，使得事务的控制更加简单和集中。通过AOP，可以在方法开始前开启事务，在方法执行完毕后提交或回滚事务，以确保数据的一致性和完整性。
安全控制：在系统中包含某些需要安全控制的操作，如登录、修改密码、授权等，可以使用AOP来实现安全控制的功能。通过AOP，可以在方法调用前进行安全性检查，例如检查用户的权限或身份验证，以确保只有授权用户可以访问特定的方法或资源。
性能监控：在系统运行过程中，有时需要对某些方法的性能进行监控，以找到系统的瓶颈并进行优化。通过AOP，可以在方法调用前后记录方法的执行时间，以监控和优化系统的性能。
缓存控制：在系统中有些数据可以缓存起来以提高访问速度，可以使用AOP来实现缓存控制的功能。通过AOP，可以在方法执行前查询缓存中是否有数据，如果有则返回，否则执行方法并将方法返回值存入缓存中。
异常处理：使用AOP，可以集中处理方法中抛出的异常，例如将异常转换为统一的错误码或进行日志记录。这有助于更好地管理和监控异常，并降低异常对系统的影响。
参数校验和转换：使用AOP，可以在方法调用前对方法的参数进行校验和转换，以确保参数的有效性和符合业务要求。这有助于减少因参数问题导致的错误和异常，并提高系统的健壮性。
12、Spring中如何开启事务？
参考回答：
编程式事务：
编程式事务是通过编程的方式自己去实现事务，比如事务的开启、提交、回滚操作，需要开发人员自己调用commit()或者rollback()等方法来实现。
这种事务管理方式需要在逻辑代码中手动书写事务控制逻辑，因此是侵入性的。它的缺点是代码复用性差，每一个事务都需要自己编写事务逻辑，可能会造成代码冗余。然而，它的优点在于事务边界更容易控制，可以在业务的任意位置进行事务提交或者回滚操作。
声明式事务：
声明式事务则是通过配置或注解的方式，将事务管理逻辑与业务逻辑进行分离，由Spring框架来自动处理事务的开启、提交和回滚。
使用声明式事务时，通常会在业务层（service层）的方法上、类上或接口上使用@Transactional注解。当方法执行前，Spring会自动开启事务；如果方法成功执行完毕，Spring会提交事务；如果方法执行过程中出现异常，Spring会回滚事务。
除了使用@Transactional注解外，还需要在主配置类（通常是应用的入口类）上使用@EnableTransactionManagement注解来启用Spring的事务管理功能。
13、Spring ioc在项目中的应用场景？（了解）
参考回答：
解耦与模块化：
在复杂的系统中，各个组件之间可能存在复杂的依赖关系。使用Spring IoC，可以将这些依赖关系交由Spring容器管理，使得组件之间的耦合度降低，提高了系统的模块化程度。
依赖注入：
Spring IoC支持依赖注入（Dependency Injection, DI），这意味着Spring容器会自动将所需的依赖项注入到对象的实例中。这使得开发者无需在代码中手动创建和管理依赖对象，从而简化了代码并提高了可读性。
配置集中管理：
Spring IoC允许开发者将配置信息（如数据库连接信息、第三方服务接口地址等）集中在一个或多个配置文件中（如XML文件、Java配置类或YAML文件）。这样，当配置信息需要变更时，只需修改配置文件而无需修改代码。
插件化开发：
在一些大型系统中，可能需要支持多种插件或扩展。通过使用Spring IoC，可以将这些插件或扩展作为独立的组件进行开发，并通过配置文件或注解将它们集成到系统中。这使得插件的添加、删除和替换变得更加容易。
测试支持：
在测试过程中，可能需要模拟或替换某些组件的依赖项。Spring IoC提供了方便的测试支持，允许开发者在测试环境中注入模拟对象或测试数据，从而验证系统的正确性。
动态代理：
Spring IoC结合AOP（Aspect-Oriented Programming，面向切面编程）可以实现动态代理。动态代理允许开发者在不修改原始代码的情况下，为类添加额外的功能（如日志记录、事务管理、性能监控等）。这使得系统的功能扩展变得更加灵活和方便。
容器化应用：
在云原生和微服务架构中，应用通常以容器的形式部署。Spring IoC作为Spring框架的核心特性之一，可以与容器化技术（如Docker、Kubernetes等）很好地结合使用。通过Spring IoC管理应用的依赖关系，可以确保应用在容器化环境中能够正常运行并与其他服务进行交互。
14、SpringBoot和Spring的区别是什么？（了解）
参考回答：
设计理念：Spring是一个全面的框架，它提供了许多功能，但同时也增加了项目的复杂度。相反，Spring Boot旨在简化Spring应用程序的初始搭建和开发过程，尽可能自动配置Spring应用程序。基于“约定优于配置”的原则，Spring Boot简化了项目的配置流程。
创建独立应用：Spring Boot可以创建独立的Spring应用程序。它集成了Tomcat、Jetty和Undertow等服务器，并且不需要部署它们。这意味着开发者可以直接打包他们的应用程序为一个可执行的JAR或WAR文件，从而简化了部署过程。
配置：在Spring中，我们需要进行大量的XML配置、JavaConfig和注解处理，以整合各种组件。而在Spring Boot中，它使用了特定的方式来进行配置，极大地简化了这些文件的配置过程。例如，Spring Boot引入了“starters”的概念，这些是预先配置好的Maven依赖项，可以简化Maven配置。
嵌入式容器：Spring Boot嵌入了一个Web服务器（如Tomcat、Jetty或Undertow），这使得应用程序可以作为一个独立的可执行JAR或WAR文件运行，而不需要单独的服务器或容器。
自动配置：Spring Boot的强大之处在于其自动配置功能。它通过检查项目的类路径、属性设置和其他条件，自动为你配置Spring应用程序。例如，如果你在类路径中添加了H2数据库，Spring Boot会自动为你配置一个内存数据库。
依赖管理：在Spring Boot中，你只需要引入相应的starter依赖，就可以快速地整合第三方库和框架。这种依赖管理方式使得项目结构更加清晰，减少了版本冲突的可能性。
15、springBean的初始化过程？
参考回答：
Bean的定义：
在Spring配置中定义Bean的信息，包括类名、属性、作用域等。
Bean的加载和解析：
Spring容器启动时，加载并解析配置文件或注解，生成BeanDefinition对象。
实例化Bean：
根据BeanDefinition，通过反射创建Bean实例。如果是单例Bean，会被缓存起来。
依赖注入：
为Bean注入所需的依赖，方式包括构造器注入、setter方法注入和字段注入。
初始化前处理：
如果存在BeanPostProcessor，调用其postProcessBeforeInitialization方法，对Bean进行初始化前的定制化处理。
调用初始化方法：
执行Bean的初始化方法，可能包括：
实现InitializingBean接口的afterPropertiesSet方法。
在配置中指定的init-method方法。
使用@PostConstruct注解的方法。
初始化后处理：
如果存在BeanPostProcessor，调用其postProcessAfterInitialization方法，对Bean进行初始化后的定制化处理，如AOP代理等。
Bean的就绪和使用：
经过上述步骤，Bean已完全初始化，可以通过getBean()方法获取并使用。
16、如何在Spring启动过程中做缓存预热？
参考回答：
监听应用启动事件：Spring框架提供了多种方式来监听应用启动事件，以便在应用启动后执行特定的逻辑。你可以使用@EventListener注解或实现ApplicationListener接口来监听ApplicationReadyEvent事件。当这个事件被触发时，意味着Spring应用已经启动并准备好接受请求了。
使用CommandLineRunner或ApplicationRunner：如果你不想直接监听ApplicationReadyEvent事件，你也可以使用CommandLineRunner或ApplicationRunner接口。这两个接口都定义了一个run方法，Spring Boot会在所有Spring Beans都初始化完成之后调用这个方法。
使用@PostConstruct注解：使用 @PostConstruct 注解标注一个方法，该方法将在 Bean 的构造函数执行完毕后立即被调用。在这个方法中执行缓存预热的逻辑。
17、spring中常用注解？
参考回答：
组件注解：
@Component：用于标识一个类为Spring的组件，可以被自动扫描并注册为Bean。
@Controller：用于标识一个类为控制器层（Controller）组件，通常用于处理HTTP请求。
@Service：用于标注业务逻辑层组件，即Service层。
@Repository：用于标识一个类为数据访问层（DAO）组件，用于操作数据库。
@RestController：结合@Controller和@ResponseBody，用于标识一个类为RESTful风格的控制器，用于返回JSON或XML数据。
注入注解：
@Autowired：由Spring提供，用于自动注入依赖。它默认按类型匹配的方式在容器查找匹配的Bean，当有且仅有一个匹配的Bean时，Spring将其注入到标注的变量中。
@Qualifier：与@Autowired配合使用，用于在存在多个相同类型的Bean时，指定要注入的Bean的名称或限定符。
@Resource：与@Autowired类似，但除了按类型匹配外，还支持按名称匹配。
@Value：用于注入配置文件中的值或表达式的结果，例如注入一个字符串或数字常量。
Java配置类相关注解：
@Configuration：用于标识一个类为配置类，通常与@Bean一起使用，以替代传统的XML配置文件。
@Bean：注解在方法上，声明当前方法的返回值为一个Bean，用于在配置类中定义Bean。
切面（AOP）相关注解：
@Aspect：声明一个切面，用于定义通知（Advice）和切点（Pointcut）。
@Before、@After、@AfterReturning、@AfterThrowing、@Around：这些注解用于定义通知，分别表示在方法执行前、后、返回后、抛出异常后和环绕方法执行通知。
其他常用注解：
@RequestMapping：用于映射Web请求到特定的处理器方法。
@PathVariable：用于从URI模板变量中解析值，并绑定到方法参数上。
@RequestParam：用于从请求参数中解析值，并绑定到方法参数上。
@RequestBody：用于将HTTP请求正文转换为Java对象。
@ResponseBody：用于将Java对象转换为HTTP响应正文。
18、spring中注入方式？
参考回答：
set()方法注入；
构造器注入：①通过index设置参数的位置；②通过type设置参数类型；
静态工厂注入；
实例工厂；
19、spring中单例Bean是线程安全的吗？
参考回答：
不是，因为所有线程共享一个单例Bean，存在资源的竞争所以是线程不安全的，实际上大部分时间Bean是无状态的，所以说在某种程度上来说Bean其实是安全的。如果是有状态，那就需要开发人员修改bean的作用域。singleton改为prototype。
20、SpringMVC的执行流程?
用户发送请求至前端控制器 DispatcherServlet。
DispatcherServlet 收到请求调用 HandlerMapping 处理器映射器。
处理器映射器找到具体的处理器(可以根据 xml 配置、注解进行查找)，生成处理器及处理器拦截器(如果有则生成)一并返回给 DispatcherServlet。
DispatcherServlet 调用 HandlerAdapter 处理器适配器。
HandlerAdapter 经过适配调用具体的处理器(Controller，也叫后端控制器)
Controller 执行完成返回 ModelAndView。
HandlerAdapter 将 controller 执行结果 ModelAndView 返回给 DispatcherServlet。
DispatcherServlet 将 ModelAndView 传给 ViewReslover 视图解析器。
ViewReslover 解析后返回具体 View。
DispatcherServlet 根据 View 进行渲染视图（即将模型数据填充至视图中）。
DispatcherServlet 响应用户。

21、解释一下DispatcherServlet的作用？(了解)
DispatcherServlet是Spring MVC的前端控制器，它负责接收所有的HTTP请求，并根据请求的类型和内容，将请求分发到相应的Controller进行处理。同时，它也负责将Controller返回的结果传递给视图进行渲染。
22、Spring MVC的主要组件？（了解）
Spring MVC的主要组件包括DispatcherServlet（前端控制器）
HandlerMapping（处理器映射器）
HandlerAdapter（处理器适配器）
Controller（控制器）
ModelAndView（模型和视图）
ViewResolver（视图解析器）。
23、SpringMVC 的常用注解有哪些？
@RequestMapping ：用于处理请求 url 映射的注解，可用于类或方法上。用于类上，则表示类中的所有响应请求的方法都是以该地址作为父路径；
@RequestBody ：注解实现接收 HTTP 请求的 json 数据，将 json 转换为 Java对象；
@ResponseBody ：注解实现将 Controller 方法返回对象转化为 json 对象响应给客户
24、@Controller注解的作用？（了解）
在Spring MVC 中，控制器Controller 负责处理由DispatcherServlet 分发的请求，它把用户请求的数据经过业务处理层处理之后封装成一个Model ，然后再把该Model 返回给对应的View 进行展示。在Spring MVC 中提供了一个非常简便的定义Controller 的方法，你无需继承特定的类或实现特定的接口，只需使用@Controller 标记一个类是Controller ，然后使用@RequestMapping 和@RequestParam 等一些注解用以定义URL 请求和Controller 方法之间的映射，这样的Controller 就能被外界访问到。此外Controller 不会直接依赖于HttpServletRequest 和HttpServletResponse 等HttpServlet 对象，它们可以通过Controller 的方法参数灵活的获取到。
@Controller 用于标记在一个类上，使用它标记的类就是一个Spring MVC Controller 对象。分发处理器将会扫描使用了该注解的类的方法，并检测该方法是否使用了@RequestMapping 注解。@Controller 只是定义了一个控制器类，而使用@RequestMapping 注解的方法才是真正处理请求的处理器。单单使用@Controller 标记在一个类上还不能真正意义上的说它就是Spring MVC 的一个控制器类，因为这个时候Spring 还不认识它。那么要如何做Spring 才能认识它呢？这个时候就需要我们把这个控制器类交给Spring 来管理。有两种方式：
在Spring MVC 的配置文件中定义MyController 的bean 对象。
在Spring MVC 的配置文件中告诉Spring 该到哪里去找标记为@Controller 的Controller 控制器。
25、Spring事务的实现方式和原理以及隔离级别？
在使用Spring框架时，可以有两种使用事务的方式，一种是编程式的，一种是申明式的， @Transactional注解就是申明式的。
首先，事务这个概念是数据库层面的，Spring只是基于数据库中的事务进行了扩展，以及提供了一些能让程序员更加方便操作事务的方式。
比如我们可以通过在某个方法上增加@Transactional注解，就可以开启事务，这个方法中所有的sql都会在一个事务中执行，统一成功或失败。
在一个方法上加了@Transactional注解后，Spring会基于这个类生成一个代理对象，会将这个代理对象作为bean，当在使用这个代理对象的方法时，如果这个方法上存在@Transactional注解，那么代理逻辑会先把事务的自动提交设置为false，然后再去执行原本的业务逻辑方法，如果执行业务逻辑方法没有出现异常，那么代理逻辑中就会将事务进行提交，如果执行业务逻辑方法出现了异常，那么则会将事务进行回滚。
当然，针对哪些异常回滚事务是可以配置的，可以利用@Transactional注解中的rollbackFor属性进行配置，默认情况下会对RuntimeException和Error进行回滚。
spring事务隔离级别：
ISOLATION_DEFAULT：这是个 PlatfromTransactionManager 默认的隔离级别，使用数据库默认的事务隔离级别。
ISOLATION_READ_UNCOMMITTED：读未提交，允许事务在执行过程中，读取其他事务未提交的数据。
ISOLATION_READ_COMMITTED：读已提交，允许事务在执行过程中，读取其他事务已经提交的数据。
ISOLATION_REPEATABLE_READ：可重复读，在同一个事务内，任意时刻的查询结果都是一致的。
ISOLATION_SERIALIZABLE：所有事务逐个依次执行。

2、说说异常分类

Throwable 是 Java 语言中所有错误或异常的超类。下一层分为 Error 和 Exception。

3、说说Error

Error 类是指 java 运行时系统的内部错误和资源耗尽错误。应用程序不会抛出该类对象。如果出现了这样的错误，除了告知用户，剩下的就是尽力使程序安全的终止。

4、说说Exception（RuntimeException、CheckedException）

Exception 又 有 两 个 分 支 ， 一 个 是 运 行 时 异 常 RuntimeException ， 一 个 是CheckedException。
RuntimeException如 ： NullPointerException 、 ClassCastException 。
检查异常CheckedException：一般是外部错误，这种异常都发生在编译阶段，Java 编译器会强制程序去捕获此类异常，即会出现要求你把这段可能出现异常的程序进行 try catch。
一 个 是 检 查 异 常CheckedException，如 I/O 错误导致的 IOException、SQLException。RuntimeException 是那些可能在 Java 虚拟机正常运行期间抛出的异常的超类。 如果出现RuntimeException，那么一定是程序员的错误。

5、说说Throw 和throws的区别

位置不同：throws 用在函数上，后面跟的是异常类，可以跟多个；而 throw 用在函数内，后面跟的是异常对象。
功能不同：
throws 用来声明异常，让调用者只知道该功能可能出现的问题，可以给出预先的处理方式；throw 抛出具体的问题对象，执行到 throw，功能就已经结束了，跳转到调用者，并将具体的问题对象抛给调用者。也就是说 throw 语句独立存在时，下面不要定义其他语句，因为执行不到。
throws 表示出现异常的一种可能性，并不一定会发生这些异常；throw 则是抛出了异常，执行throw 则一定抛出了某种异常对象。
两者都是消极处理异常的方式，只是抛出或者可能抛出异常，但是不会由函数去处理异常，真正的
处理异常由函数的上层调用处理。

操作系统
1、同步、异步、阻塞、非阻塞怎么理解？
同步和异步描述的是被调用者的执行方式，例如，当A调用B时，同步情况下B会立即执行要做的事情，并确保A的调用能够得到结果；异步情况下，B在接收到A的调用后，并不立即执行，但会承诺在完成后通知A，A的本次调用无法立即得到结果。
阻塞和非阻塞描述的是调用者的等待方式，比如，当A调用B时，阻塞情况下A会一直等待B返回结果；非阻塞情况下，A在调用B后可以继续执行其他任务，而不需要一直等待B的返回。
举个例子，以老张烧水为例：
同步阻塞： 老张放水壶在火上，一直等着水开，直到水开了才返回。
同步非阻塞： 老张放水壶在火上，然后去客厅看电视，时不时去厨房看看水开没有，但不需要一直等待。
异步阻塞： 老张放能响的水壶在火上，一直等着水开，但不一定立即开始烧水。
异步非阻塞： 老张放能响的水壶在火上，然后去客厅看电视，不再去厨房关心水壶，直到水壶响了再去拿壶。
2、什么是用户态、内核态？如何切换的
在计算机系统中，内核充当操作系统的核心，负责有效管理和控制硬件资源，同时提供各类系统服务。若所有应用程序都可以直接访问硬件资源，可能导致系统稳定性和数据安全方面的问题。
因此，为确保内核能独立掌控硬件资源，操作系统将应用程序和内核进行了隔离。内核在特权模式下运行，具备对所有硬件资源和底层系统资源的访问权限，而应用程序在非特权模式下运行，仅能访问被授权的资源，无法直接操纵硬件和底层系统资源。
具体而言，内核态表示操作系统以特权模式运行，有权访问处理器、内存、I/O等所有硬件资源。在内核态下，操作系统能执行所有指令，无受访问权限限制。内核态通常包括操作系统内核代码和设备驱动程序，能直接访问硬件和系统资源，实现系统功能和服务。
用户态指应用程序在非特权模式下运行，仅能访问受限的资源，无法直接操作硬件和底层系统资源。在用户态下，应用程序只能执行限定的指令集，不能直接执行特权指令。当应用程序需访问系统资源时，需通过系统调用方式切换到内核态，请求操作系统提供服务。内核态与用户态之间的切换通过操作系统内核提供的中断或异常机制实现。
在某些情况下，应用进程可能需要进行系统调用，如进行文件读写等I/O操作，从而触发用户态向内核态的切换。此时，CPU会暂停当前进程执行，保存其状态（包括程序计数器、寄存器、栈指针等），切换至内核态执行相关操作，完成后再切回用户态，继续进程执行。
3、什么是全双工和半双工
单工： 单工通信限定数据在一个方向传输，信息只能从一个点发送到另一个点。通信的一方仅能发送数据，而另一方则只能接收。广播电台提供了典型的单工通信示例，听众只能接收广播，无法向电台发送信息。
半双工： 在半双工通信中，数据能够在通信双方之间双向传输，但无法同时进行。换言之，通信的两端可以轮流发送和接收数据，但不能同时执行这两个操作。对讲机的工作原理就是半双工通信的典型案例，一方说话时，另一方只能听，无法同时说话。
全双工： 全双工通信允许数据在通信双方之间双向同时传输。每一方都能独立地发送和接收数据，而这两个操作可以同时进行。电话通信是全双工通信的例子，两个人可以同时说话而互不干扰。
在计算机网络中，通过TCP连接进行通信时，可以实现全双工通信，允许数据在两个方向上同时传输。

4、操作系统的IO模型有哪些？
阻塞 I/O（blocking IO）
在linux中，最简单常用的网络I/O模型是所有socket都blocking的阻塞I/O，根据经典教程unix网络的描述，它的流程如下图:

当用户向内核发起了请求获取的数据的系统调用后，CPU会从用户态切换到内核态。当kernel一直等到数据准备好了即数据已从网卡写入到内核缓冲区，接着CPU就会将数据从内核空间中拷贝到用户内存，然后kernel返回结果，用户进程才解除阻塞状态，重新运行起来。 所以，blocking IO的特点就是在IO执行的两个阶段都被block了。
非阻塞I/O（nonblocking IO）
linux下，可以将secket通信设置为non-blocking。其流程如下图所示：

该模式下用户程序在使用系统调用向内核请求数据时，会告诉内核如果数据没准备好返回ERROR而不是让用户程序阻塞。从用户程序角度讲 ，它发起一个read操作后，并不需要等待，而是马上就得到了一个结果。用户程序判断结果是一个error时，它就知道数据还没有准备好，于是它可以再次发送read操作。一旦kernel中的数据准备好了，并且又再次收到了用户进程的system call，那么它马上就将数据拷贝到了用户内存，然后返回。所以，在nonblocking IO中用户程序需要不断的主动询问kernel数据好了没有。这通常会浪费CPU时间，但是通常在专用于一个功能的系统上偶尔会遇到此模型。
多路复用（IO multiplexing）
多路复用IO是一个非常重要的IO模型，这种IO模型在有些地方被称为event driven IO。在这种模式下又分为3种机制，select\poll\epoll，相同的是它们都会不断的轮询所负责的所有socket，当某个socket有数据到达了，就通知用户进程。流程图如下：

在这种模式下用户程序会用select这个系统调用开始监视所有负责的socket，如果任何数据准备好select会终止阻塞并返回。然后程序再用另一个系统调用将数据从内核空间读取到用户空间。这个模型精妙之处在于用2个进程分别处理2类阻塞。监控CPU是否将数据准备好的进程同时处理多个链接，而拷贝数据则交给另一类进程。这种模式的优点是可以处理多个connection。如果处理的链接数不是很高的话，这种模式不一定定比使用multi-threading + blocking IO的web server性能更好，可能延迟还更大（使用了2种2次系统调用，blocking只用1次阻塞1次）。在是实际的IO multiplexing Model中，对于每一个socket，一般都设置成为non-blocking，但是，如上图所示，整个用户的process其实是一直被block的。只不过process是被select这个函数block，而不是被socket IO给block。
信号驱动 I/O（signal driven IO）
在信号驱动I/O的模式下用户程序告诉内核，当内核数据准备好后使用SIGIO信号通知用户程序。具体流程如下

在这种模式下用户程序需要先准备好SignalDriven I/O的socket，使用sigaction系统调用。这时内核会立马返回，用户程序可以继续运行。此处它是非阻塞的。当报文已经保存到内核缓冲区后，内核会返回针对我们程序的SIGIO信号，然后用户程序就可以将数据从内核空间读到用户空间了。这种方式的最大好处就是在等待数据准备完成时不会阻塞用户程序。
异步 I/O（asynchronous IO）
异步I/O是POSIX定义的规范。这种模式与信号驱动类似，不同的是内核会在数据已经完全进入用户空间后再通知用户程序，而不是数据准备好就通知用户程序。流程如下图

用户程序使用aio_read开始异步I/O，同时还需要告诉内核descriptor,buffer指针,buffer大小(read也是这3个变量),file offset以及如何通知用户程序传输完成。该调用立刻返回，不会阻塞去等待IO完成。在上图的例子中展示的操作系统使用信号量的方式通知用户程序数据已读去完成。
5、你掌握哪些Linux常用命令？
我掌握很多常用的Linux命令，以下是其中的一些：
文件和目录操作：
ls: 列出目录内容
cd: 切换目录
pwd: 显示当前工作目录
cp: 复制文件或目录
mv: 移动文件或目录
rm: 删除文件或目录
mkdir: 创建目录
文件查看和编辑：
cat: 显示文件内容
more: 逐屏显示文件内容
less: 以交互方式逐屏显示文件内容
nano 或 vim: 文本编辑器
3.文件权限和所有权：
chmod: 修改文件权限
chown: 修改文件所有者
chgrp: 修改文件所属组
查找和定位文件：
find: 查找文件
grep: 在文件中搜索文本
locate: 使用数据库快速查找文件
压缩和解压缩：
tar: 打包和解包文件
gzip, bzip2: 压缩和解压缩文件
系统信息和状态：
uname: 显示系统信息
df: 显示磁盘空间使用情况
du: 显示目录空间使用情况
top 或 htop: 显示系统进程和资源使用情况
进程管理：
ps: 显示当前运行的进程
kill: 终止进程
网络操作：
ping: 测试网络连接
ifconfig 或 ip: 显示网络接口配置信息
netstat: 显示网络状态信息
用户和权限管理：
useradd: 添加用户
passwd: 修改用户密码
userdel: 删除用户
su: 切换用户
sudo: 以管理员权限执行命令
6、什么是操作系统的多级缓存
计算机执行程序时，每条指令都在CPU中执行，与数据交互时则需要访问主存，即计算机的物理内存。随着CPU技术的进步，其执行速度显著提高，而内存技术相对较为滞后，导致CPU操作内存时需要花费较多等待时间。
为解决内存速度与CPU执行速度之间的差距，人们引入了高速缓存的概念。缓存是一种保存数据拷贝的方式，具有快速、小容量、昂贵的特点。程序的执行过程变为：
在运行过程中，程序将运算所需的数据从主存复制到CPU的高速缓存中。CPU进行计算时直接从高速缓存读取和写入数据，计算结束后再将数据刷新到主存中。随着CPU性能提升，单一缓存逐渐无法满足需求，出现了多级缓存。
根据数据读取顺序和与CPU结合的紧密程度，CPU缓存可分为一级缓存（L1）、二级缓存（L2），高端CPU可能还有三级缓存（L3）。每级缓存中存储的数据都是下一级缓存的一部分。多级缓存的引入使程序执行变为：
CPU读取数据时首先查找一级缓存，未找到则查找二级缓存，依此类推，直至找到或在内存中查找。单核CPU拥有一套L1、L2、L3缓存，而多核CPU的每个核心都有一套L1（有时与L2）缓存，共享L3（或与L2）缓存。
7、进程和线程的区别？
调度：进程是资源管理的基本单位，线程是程序执行的基本单位。
切换：线程上下文切换比进程上下文切换要快得多。
拥有资源：进程是拥有资源的一个独立单位，线程不拥有系统资源，但是可以访问隶属于进程的资源。
系统开销：创建或撤销进程时，系统都要为之分配或回收系统资源，如内存空间，I/O设备等，OS所付出的开销显著大于在创建或撤销线程时的开销，进程切换的开销也远大于线程切换的开销。
8、协程与线程的区别？
线程和进程都是同步机制，而协程是异步机制。
线程是抢占式，而协程是非抢占式的。需要用户释放使用权切换到其他协程，因此同一时间其实只有一个协程拥有运行权，相当于单线程的能力。
协程能保留上一次调用时的状态。
9、进程间同步的方式有哪些？
临界区：通过对多线程的串行化来访问公共资源或一段代码，速度快，适合控制数据访问。
优点：保证在某一时刻只有一个线程能访问数据的简便办法。
缺点：虽然临界区同步速度很快，但却只能用来同步本进程内的线程，而不可用来同步多个进程中的线程。
互斥量：为协调共同对一个共享资源的单独访问而设计的。互斥量跟临界区很相似，比临界区复杂，互斥对象只有一个，只有拥有互斥对象的线程才具有访问资源的权限。
优点：使用互斥不仅仅能够在同一应用程序不同线程中实现资源的安全共享，而且可以在不同应用程序的线程之间实现对资源的安全共享。
缺点：互斥量是可以命名的，也就是说它可以跨越进程使用，所以创建互斥量需要的资源更多，所以如果只为了在进程内部是用的话使用临界区会带来速度上的优势并能够减少资源占用量。
通过互斥量可以指定资源被独占的方式使用，但如果有下面一种情况通过互斥量就无法处理，比如现在一位用户购买了一份三个并发访问许可的数据库系统，可以根据用户购买的访问许可数量来决定有多少个线程/进程能同时进行数据库操作，这时候如果利用互斥量就没有办法完成这个要求，信号量对象可以说是一种资源计数器。
信号量：为控制一个具有有限数量用户资源而设计。它允许多个线程在同一时刻访问同一资源，但是需要限制在同一时刻访问此资源的最大线程数目。互斥量是信号量的一种特殊情况，当信号量的最大资源数=1就是互斥量了。
优点：适用于对Socket（套接字）程序中线程的同步。
缺点:信号量机制必须有公共内存，不能用于分布式操作系统，这是它最大的弱点；
信号量机制功能强大，但使用时对信号量的操作分散， 而且难以控制，读写和维护都很困难，加重了程序员的编码负担；
核心操作P-V分散在各用户程序的代码中，不易控制和管理，一旦错误，后果严重，且不易发现和纠正。
事件： 用来通知线程有一些事件已发生，从而启动后继任务的开始。
10、线程同步的方式有哪些？
临界区：当多个线程访问一个独占性共享资源时，可以使用临界区对象。拥有临界区的线程可以访问被保护起来的资源或代码段，其他线程若想访问，则被挂起，直到拥有临界区的线程放弃临界区为止，以此达到用原子方式操 作共享资源的目的。
事件：事件机制，则允许一个线程在处理完一个任务后，主动唤醒另外一个线程执行任务。
互斥量：互斥对象和临界区对象非常相似，只是其允许在进程间使用，而临界区只限制与同一进程的各个线程之间使用，但是更节省资源，更有效率。
信号量：当需要一个计数器来限制可以使用某共享资源的线程数目时，可以使用“信号量”对象。
区别：互斥量与临界区的作用非常相似，但互斥量是可以命名的，也就是说互斥量可以跨越进程使用，但创建互斥量需要的资源更多，所以如果只为了在进程内部是用的话使用临界区会带来速度上的优势并能够减少资源占用量 。因为互斥量是跨进程的互斥量一旦被创建，就可以通过名字打开它。
互斥量，信号量，事件都可以被跨越进程使用来进行同步数据操作。
11、什么是死锁？死锁产生的条件？
什么是死锁：
在两个或者多个并发进程中，如果每个进程持有某种资源而又等待其它进程释放它或它们现在保持着的资源，在未改变这种状态之前都不能向前推进，称这一组进程产生了死锁。通俗的讲就是两个或多个进程无限期的阻塞、相互等待的一种状态。
死锁产生的四个必要条件：（有一个条件不成立，则不会产生死锁）
互斥条件：一个资源一次只能被一个进程使用
请求与保持条件：一个进程因请求资源而阻塞时，对已获得资源保持不放
不剥夺条件：进程获得的资源，在未完全使用完之前，不能强行剥夺
循环等待条件：若干进程之间形成一种头尾相接的环形等待资源关系
如何处理死锁问题
常用的处理死锁的方法有：死锁预防、死锁避免、死锁检测、死锁解除、鸵鸟策略。
死锁的预防： 基本思想就是确保死锁发生的四个必要条件中至少有一个不成立：、
死锁避免：
死锁预防通过约束资源请求，防止4个必要条件中至少一个的发生，可以通过直接或间接预防方法，但是都会导致低效的资源使用和低效的进程执行。而死锁避免则允许前三个必要条件，但是通过动态地检测资源分配状态，以确保循环等待条件不成立，从而确保系统处于安全状态。所谓安全状态是指：如果系统能按某个顺序为每个进程分配资源（不超过其最大值），那么系统状态是安全的，换句话说就是，如果存在一个安全序列，那么系统处于安全状态。银行家算法是经典的死锁避免的算法。
死锁检测：
死锁预防策略是非常保守的，他们通过限制访问资源和在进程上强加约束来解决死锁的问题。死锁检测则是完全相反，它不限制资源访问或约束进程行为，只要有可能，被请求的资源就被授权给进程。但是操作系统会周期性地执行一个算法检测前面的循环等待的条件。死锁检测算法是通过资源分配图来检测是否存在环来实现，从一个节点出发进行深度优先搜索，对访问过的节点进行标记，如果访问了已经标记的节点，就表示有存在环，也就是检测到死锁的发生。
死锁解除：
死锁解除的常用方法就是终止进程和资源抢占，回滚。所谓进程终止就是简单地终止一个或多个进程以打破循环等待，包括两种方式：终止所有死锁进程和一次只终止一个进程直到取消死锁循环为止；所谓资源抢占就是从一个或者多个死锁进程那里抢占一个或多个资源。
鸵鸟策略：
把头埋在沙子里，假装根本没发生问题。因为解决死锁问题的代价很高，因此鸵鸟策略这种不采取任何措施的方案会获得更高的性能。当发生死锁时不会对用户造成多大影响，或发生死锁的概率很低，可以采用鸵鸟策略。大多数操作系统，包括 Unix，Linux 和 Windows，处理死锁问题的办法仅仅是忽略它。
12、什么是死锁？死锁产生的条件？
先来先服务：非抢占式的调度算法，按照请求的顺序进行调度。有利于长作业，但不利于短作业，因为短作业必须一直等待前面的长作业执行完毕才能执行，而长作业又需要执行很长时间，造成了短作业等待时间过长。另外，对I/O密集型进程也不利，因为这种进程每次进行I/O操作之后又得重新排队。
短作业优先：非抢占式的调度算法，按估计运行时间最短的顺序进行调度。长作业有可能会饿死，处于一直等待短作业执行完毕的状态。因为如果一直有短作业到来，那么长作业永远得不到调度。
最短剩余时间优先：最短作业优先的抢占式版本，按剩余运行时间的顺序进行调度。 当一个新的作业到达时，其整个运行时间与当前进程的剩余时间作比较。如果新的进程需要的时间更少，则挂起当前进程，运行新的进程。否则新的进程等待。
时间片轮转：将所有就绪进程按 FCFS 的原则排成一个队列，每次调度时，把 CPU 时间分配给队首进程，该进程可以执行一个时间片。当时间片用完时，由计时器发出时钟中断，调度程序便停止该进程的执行，并将它送往就绪队列的末尾，同时继续把 CPU 时间分配给队首的进程。
时间片轮转算法的效率和时间片的大小有很大关系：因为进程切换都要保存进程的信息并且载入新进程的信息，如果时间片太小，会导致进程切换得太频繁，在进程切换上就会花过多时间。 而如果时间片过长，那么实时性就不能得到保证。
优先级调度：为每个进程分配一个优先级，按优先级进行调度。为了防止低优先级的进程永远等不到调度，可以随着时间的推移增加等待进程的优先级。
13、进程有哪些状态？
进程一共有5种状态，分别是创建、就绪、运行（执行）、终止、阻塞。

运行状态就是进程正在CPU上运行。在单处理机环境下，每一时刻最多只有一个进程处于运行状态。
就绪状态就是说进程已处于准备运行的状态，即进程获得了除CPU之外的一切所需资源，一旦得到CPU即可运行。
阻塞状态就是进程正在等待某一事件而暂停运行，比如等待某资源为可用或等待I/O完成。即使CPU空闲，该进程也不能运行。
运行态→阻塞态：往往是由于等待外设，等待主存等资源分配或等待人工干预而引起的。
阻塞态→就绪态：则是等待的条件已满足，只需分配到处理器后就能运行。
运行态→就绪态：不是由于自身原因，而是由外界原因使运行状态的进程让出处理器，这时候就变成就绪态。例如时间片用完，或有更高优先级的进程来抢占处理器等。
就绪态→运行态：系统按某种策略选中就绪队列中的一个进程占用处理器，此时就变成了运行态。
14、进程有哪些状态？
用户态和系统态是操作系统的两种运行状态：
内核态：内核态运行的程序可以访问计算机的任何数据和资源，不受限制，包括外围设备，比如网卡、硬盘等。处于内核态的 CPU 可以从一个程序切换到另外一个程序，并且占用 CPU 不会发生抢占情况。
用户态：用户态运行的程序只能受限地访问内存，只能直接读取用户程序的数据，并且不允许访问外围设备，用户态下的 CPU 不允许独占，也就是说 CPU 能够被其他程序获取。
将操作系统的运行状态分为用户态和内核态，主要是为了对访问能力进行限制，防止随意进行一些比较危险的操作导致系统的崩溃，比如设置时钟、内存清理，这些都需要在内核态下完成 。
15、用户态和内核态是如何切换的?
所有的用户进程都是运行在用户态的，但是我们上面也说了，用户程序的访问能力有限，一些比较重要的比如从硬盘读取数据，从键盘获取数据的操作则是内核态才能做的事情，而这些数据却又对用户程序来说非常重要。所以就涉及到两种模式下的转换，即用户态 -＞ 内核态 -＞ 用户态，而唯一能够做这些操作的只有 系统调用，而能够执行系统调用的就只有 操作系统。
一般用户态 -＞ 内核态的转换我们都称之为 trap 进内核，也被称之为 陷阱指令(trap instruction)。
他们的工作流程如下：

首先用户程序会调用 glibc 库，glibc 是一个标准库，同时也是一套核心库，库中定义了很多关键 API。
glibc 库知道针对不同体系结构调用系统调用的正确方法，它会根据体系结构应用程序的二进制接口设置用户进程传递的参数，来准备系统调用。
然后，glibc 库调用软件中断指令(SWI) ，这个指令通过更新 CPSR 寄存器将模式改为超级用户模式，然后跳转到地址 0x08 处。
到目前为止，整个过程仍处于用户态下，在执行 SWI 指令后，允许进程执行内核代码，MMU 现在允许内核虚拟内存访问
从地址 0x08 开始，进程执行加载并跳转到中断处理程序，这个程序就是 ARM 中的 vector_swi()。
在 vector_swi() 处，从 SWI 指令中提取系统调用号 SCNO，然后使用 SCNO 作为系统调用表 sys_call_table 的索引，调转到系统调用函数。
执行系统调用完成后，将还原用户模式寄存器，然后再以用户模式执行。

1、网络7层架构是什么？

应用层（数据）：确定进程之间通信的性质以满足用户需要以及提供网络与用户应用
表示层（数据）：主要解决拥护信息的语法表示问题，如加密解密
会话层（数据）：提供包括访问验证和会话管理在内的建立和维护应用之间通信的机制，如服务器验证用户登录便是由会话层完成的
运输层（段）：实现网络不同主机上用户进程之间的数据通信，可靠与不可靠的传输，传输层的错误检测，流量控制等
网络层（包）：提供逻辑地址（IP）、选路，数据从源端到目的端的传输
数据链路层（帧）：也称MAC层，将上层数据封装成帧，用MAC地址访问媒介，错误检测与修正
物理层（比特流）：设备之间比特流的传输，物理接口，电气特性等
2、TCP/IP 四层模型？
应用层：对应于OSI参考模型的（应用层、表示层、会话层）。
传输层: 对应OSI的传输层，为应用层实体提供端到端的通信功能，保证了数据包的顺序传送及数据的完整性。
网际层：对应于OSI参考模型的网络层，主要解决主机到主机的通信问题。
网络接口层：与OSI参考模型的数据链路层、物理层对应。
3、请简单说下ARP协议的工作过程？
每个主机都会有自己的ARP缓存区中建立一个ARP列表，以表示IP地址和MAC地址之间的对应关系
当源主机要发送数据时，首先检测ARP列表中是否对应IP地址的目的主机的MAC地址，如果有，则直接发送数据，如果没有，就向本网段的所有主机发送ARP数据包，内容：我是IP地址，mac地址，谁是目标IP地址，目标mac？
当本网络的所有主机收到该ARP数据包时，首先检查数据包中的IP地址是否是自己的IP地址，如果不是，则忽略该数据包，如果是，则首先从数据包中取出源主机的IP和mac地址写入到ARP列表中，如果以存在，则覆盖，然后将自己的mac地址写入arp响应包中，告诉源主机自己是它想要找的mac地址 。
源主机收到ARP响应包后，将目的主机的IP和mac地址写入arp列表，并利用此信息发送数据，如果源主机一直没有收到arp响应数据包，表示arp查询失败。
4、请简单说下ARP协议的工作过程？
网络层的 ARP 协议完成了 IP 地址与物理地址的映射。首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。
此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败。
5、TCP和UDP什么区别？
TCP 是面向连接的，UDP 是面向无连接的。在互通之前，面向连接的协议会先建立连接。例如，TCP 会三次握手，而 UDP 不会。

6、详细说下 TCP 三次握手的过程？
三次握手
TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。

最初客户端和服务端都处于 CLOSED(关闭) 状态。本例中 A（Client） 主动打开连接，B（Server） 被动打开连接。
一开始，B 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。
第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。然后，在打算建立 TCP 连接时，向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。TCP 规定，SYN 报文段（即 SYN = 1 的报文段）不能携带数据，但要消耗掉一个序号。这时，TCP 客户进程进入 SYN-SENT（同步已发送）状态。
第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时 TCP 服务端进程进入 SYN-RCVD（同步收到）状态。
第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y + 1，而自己的序号 seq = x + 1。这时 ACK 报文段可以携带数据。但如果不携带数据则不消耗序号，这种情况下，下一个数据报文段的序号仍是 seq = x + 1。这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。
7、为什么两次握手不可以呢？
为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。比如下面这种情况：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。
对于上面这种情况，如果不进行第三次握手，B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。
如果采用了三次握手，由于 A 实际上并没有发出建立连接请求，所以不会理睬 B 的确认，也不会向 B 发送数据。B 由于收不到确认，就知道 A 并没有要求建立连接。
8、为什么不需要四次握手？
有人可能会说 A 发出第三次握手的信息后在没有接收到 B 的请求就已经进入了连接状态，那如果 A 的这个确认包丢失或者滞留了怎么办？
我们需要明白一点，完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。
9、详细说下 TCP 四次挥手的过程？
据传输结束后，通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。

第一次挥手：A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。A 把连接释放报文段首部的终止控制位 FIN 置 1，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），这时 A 进入 FIN-WAIT-1（终止等待1）状态，等待 B 的确认。请注意：TCP 规定，FIN 报文段即使不携带数据，也将消耗掉一个序号。
第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），然后 B 就进入 CLOSE-WAIT（关闭等待）状态。TCP 服务端进程这时应通知高层应用进程，因而从 A 到 B 这个方向的连接就释放了，这时的 TCP 连接处于半关闭（half-close）状态，即 A 已经没有数据要发送了，但 B 若发送数据，A 仍要接收。也就是说，从 B 到 A 这个方向的连接并未关闭，这个状态可能会持续一段时间。A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态，等待 B 发出的连接释放报文段。
第三次挥手：若 B 已经没有要向 A 发送的数据，其应用进程就通知 TCP 释放连接。这时 B 发出的连接释放报文段必须使 FIN = 1。假定 B 的序号为 w（在半关闭状态，B 可能又发送了一些数据）。B 还必须重复上次已发送过的确认号 ack = u + 1。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。
第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1（前面发送的 FIN 报文段要消耗一个序号）。然后进入 TIME-WAIT(时间等待) 状态。请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，A 才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果 B 一收到 A 的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，B 结束 TCP 连接的时间要早于 A。
10、TCP 协议是如何保证可靠传输的？
数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；
丢弃重复数据：对于重复数据，能够丢弃重复数据；
应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；
超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。
11、谈下你对 TCP 拥塞控制的理解？使用了哪些算法？
拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。
拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。
慢开始：
慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。cwnd 初始值为 1，每经过一个传播轮次，cwnd 加倍。
拥塞避免：
拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1。
快重传与快恢复：
在 TCP/IP 中，快速重传和快恢复（fast retransmit and recovery，FRR）是一种拥塞控制算法，它能快速恢复丢失的数据包。
没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。
有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和快恢复（FRR）能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时，它则不能很有效地工作。
11、说下 GET 和 POST 的区别？
GET 和 POST 本质都是 HTTP 请求，只不过对它们的作用做了界定和适配，并且让他们适应各自的场景。
本质区别：GET 只是一次 HTTP请求，POST 先发请求头再发请求体，实际上是两次请求。
从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；
从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；
从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的 请求头 中，以 ? 分割 URL 和传输数据，参数之间以 & 相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中 ％XX 中的 XX 为该符号以 16 进制表示的 ASCII)；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中；
就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全；
从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。
12、什么是 Cookie 和 Session ？
什么是 Cookie？
HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。
Cookie 主要用于以下三个方面：
会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等）
什么是 Session？
Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。
13、Cookie 和 Session 的区别？
作用范围不同，Cookie 保存在客户端（浏览器），Session 保存在服务器端。
存取方式的不同，Cookie 只能保存 ASCII，Session 可以存任意数据类型，一般情况下我们可以在 Session 中保持一些常用变量信息，比如说 UserId 等。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性相对 Cookie 要好一些。
存储大小不同， 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。
14、对称加密与非对称加密有什么区别？
对称加密：指加密和解密使用同一密钥，优点是运算速度较快，缺点是如何安全将密钥传输给另一方。常见的对称加密算法有：DES、AES等。

非对称加密：指的是加密和解密使用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥才能解密。常见的非对称加密算法有RSA。

15、Http请求的过程与原理?
HTTP是一个基于TCP/IP协议来传递数据的超文本传输协议，传输的数据类型有HTML,图片等。以访问百度有例子，看下一次Http的请求过程吧

Http请求过程
客户端进行DNS域名解析，得到对应的IP地址
根据这个IP，找到对应的服务器建立连接（三次握手）
建立TCP连接后发起HTTP请求（一个完整的http请求报文）
服务器响应HTTP请求，客户端得到html代码
客户端解析html代码，用html代码中的资源(如js,css,图片等等)渲染页面。
服务器关闭TCP连接（四次挥手）
16、说说ARP与RARP 的区别？
ARP（Address Resolution Protocol）和RARP（Reverse Address Resolution Protocol）都是用于在网络通信中进行地址转换的协议，但它们在功能、工作方式和用途上有一些区别。
功能不同：
ARP协议用于将IP地址转换为MAC地址。在通信过程中，当一台主机需要知道另一台主机的MAC地址时，它可以使用ARP协议查询目标主机的MAC地址。
RARP协议则用于将MAC地址转换为IP地址。在启动过程中，当一台主机需要知道自己的IP地址时，可以向网络中发送RARP请求，以获取自己的IP地址。
工作方式不同：
ARP协议是一种广播协议。当主机需要知道另一台主机的MAC地址时，它在本地局域网上广播一个ARP请求包，只有目标主机会响应并将自己的MAC地址发送回来。
RARP协议则是向预定义的RARP服务器发送请求，请求服务器返回自己的IP地址。
用途不同：
由于现代操作系统和网络设备能够自动分配IP地址，RARP协议的使用已经相对较少。
ARP协议在现代网络通信中仍然扮演着重要的角色，用于解析目标主机的MAC地址。
总体而言，ARP和RARP在网络中的地址解析过程中有各自的功能和应用场景，根据需求选择合适的协议。
17、TCP/IP原理？
TCP/IP 协议不是 TCP 和 IP 这两个协议的合称，而是指因特网整个 TCP/IP 协议族。从协议分层模型方面来讲，TCP/IP 由四个层次组成：网络接口层、网络层、传输层、应用层。

网络访问层(Network Access Layer)
网络访问层(Network Access Layer)在 TCP/IP 参考模型中并没有详细描述，只是指出主机必须使用某种协议与网络相连。
网络层(Internet Layer)
网络层(Internet Layer)是整个体系结构的关键部分，其功能是使主机可以把分组发往任何网络，并使分组独立地传向目标。这些分组可能经由不同的网络，到达的顺序和发送的顺序也可能不同。高层如果需要顺序收发，那么就必须自行处理对分组的排序。互联网层使用因特网协议(IP，Internet Protocol)。
传输层(Tramsport Layer-TCP/UDP)
传输层(Tramsport Layer)使源端和目的端机器上的对等实体可以进行会话。在这一层定义了两个端到端的协议：传输控制协议(TCP，Transmission Control Protocol)和用户数据报协议(UDP，User Datagram Protocol)。TCP 是面向连接的协议，它提供可靠的报文传输和对上层应用的连接服务。为此，除了基本的数据传输外，它还有可靠性保证、流量控制、多路复用、优先权和安全性控制等功能。UDP 是面向无连接的不可靠传输的协议，主要用于不需要 TCP 的排序和流量控制等功能的应用程序。
应用层(Application Layer)
应用层(Application Layer)包含所有的高层协议，包括：虚拟终端协议(TELNET，TELecommunicationsNETwork)、文件传输协议(FTP，File Transfer Protocol)、电子邮件传输协议(SMTP，Simple Mail Transfer Protocol)、域名服务(DNS，Domain Name Service)、网上新闻传输协议(NNTP，Net News Transfer Protocol)和超文本传送协议(HTTP，HyperText Transfer Protocol)等。
18、说下CDN 原理？
CND 一般包含分发服务系统、负载均衡系统和管理系统
分发服务系统
其基本的工作单元就是各个 Cache 服务器。负责直接响应用户请求，将内容快速分发到用户；同时还负责内容更新，保证和源站内容的同步。根据内容类型和服务种类的不同，分发服务系统分为多个子服务系统，如：网页加速服务、流媒体加速服务、应用加速服务等。每个子服务系统都是一个分布式的服务集群，由功能类似、地域接近的分布部署的Cache 集群组成。在承担内容同步、更新和响应用户请求之外，分发服务系统还需要向上层的管理调度系统反馈各个Cache 设备的健康状况、响应情况、内容缓存状况等，以便管理调度系统能够根据设定的策略决定由哪个 Cache 设备来响应用户的请求。
负载均衡系统：
负载均衡系统是整个 CDN 系统的中枢。负责对所有的用户请求进行调度，确定提供给用户的最终访问地址。
使用分级实现。最基本的两极调度体系包括全局负载均衡（GSLB）和本地负载均衡（SLB）。
GSLB 根据用户地址和用户请求的内容，主要根据就近性原则，确定向用户服务的节点。一般通过 DNS 解析或者应用层重定向（Http 3XX 重定向）的方式实现。
SLB 主要负责节点内部的负载均衡。当用户请求从 GSLB 调度到 SLB 时，SLB 会根据节点内各个Cache 设备的工作状况和内容分布情况等对用户请求重定向。SLB 的实现有四层调度（LVS）、七层调度（Nginx）和链路负载调度等。
管理系统：分为运营管理和网络管理子系统。
网络管理系统实现对 CDN 系统的设备管理、拓扑管理、链路监控和故障管理，为管理员提供对全网资源的可视化的集中管理，通常用 web 方式实现。
运营管理是对 CDN 系统的业务管理，负责处理业务层面的与外界系统交互所必须的一些收集、整理、交付工作。包括用户管理、产品管理、计费管理、统计分析等。

设计模式（选几个自己熟悉的深入了解一下，是怎样实现的和在项目中是怎么使用的）
1、Java的动态代理如何实现？
参考回答：
Java中的动态代理是一种在运行时动态生成代理类及其对象的技术。它主要用于实现AOP（面向切面编程）的思想，允许你在不修改原始类代码的情况下，增加新的功能或行为。动态代理通常用于实现接口，通过接口定义业务方法，并在运行时动态为接口生成实现类。
Java中的动态代理指的是在运行时动态创建代理类和对象的机制，它允许开发者在运行时确定代理类的行为。实现动态代理主要有以下两种方式：
使用JDK提供的Proxy类和InvocationHandler接口： 通过实现InvocationHandler接口创建自己的调用处理器，然后使用Proxy类的静态方法newProxyInstance()创建代理对象。JDK代理是通过实现接口的方式实现的。
使用CGLIB库：CGLIB是一个基于ASM的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成，CGLIB通过继承方式实现代理。
2、静态代理和动态代理的区别？
参考回答：
静态代理是在编译期确定的，而动态代理是在运行期确定的。静态代理需要手动编写代理类的代码，可能会导致代码冗余和繁琐，特别是在代理的类方法较多或需要同时代理多个对象的情况下，这会增加不必要的复杂性。
动态代理是通过在运行时生成代理对象，避免了手动编写代理类的繁琐过程。这使得动态代理更加灵活，尤其适用于需要代理的类方法较多或动态代理多个对象的情况。动态代理的实现更加自动化，能够在运行期根据需要生成代理，减少了手动编写代理类的工作，提高了代码的可维护性和灵活性。
3、设计模式的基本原则？
参考回答：
面向对象的基本原则主要包括以下几个核心原则：
单一职责原则（Single Responsibility Principle, SRP）：一个类最好只做一件事
单一职责原则是指一个类应该只负责一个明确的职责或功能。它通过将不同的职责分离到不同的类中，提高了代码的可读性、可维护性和可扩展性，并降低了系统的耦合性。
开放封闭原则（Open-Close Principle, OCP）： 对扩展开放、对修改封闭
开放封闭原则是指软件实体应该对扩展开放，对修改封闭。它通过扩展现有的代码来实现新功能，而不是直接修改已有的代码。遵循开放封闭原则可以提高代码的可维护性和可扩展性，降低系统的耦合性。
里氏替换原则（Liskov Substitution Principle, LSP）：子类必须能够替换其基类
里氏替换原则是指任何基类的实例都可以在程序中被其子类的实例替换，而不会影响程序的正确性。遵循里氏替换原则可以提高代码的可靠性、可扩展性和可维护性。
依赖倒置原则（Dependency Inversion Principle, DIP）：程序要依赖于抽象接口，而不是具体的实现
依赖倒置原则是指高层模块不应该依赖于低层模块，它们应该通过抽象来互相依赖。遵循依赖倒置原则可以提高代码的灵活性、可扩展性、可维护性和可测试性。
接口隔离原则（Interface Segregation Principle, ISP）：将庞大的接口拆分成更小的、更具体的接口
接口隔离原则是指接口应该尽可能小，客户端不应该依赖它不需要的接口。遵循接口隔离原则可以实现高内聚、低耦合的代码设计，提高代码的可维护性、可扩展性和可测试性。
4、各种设计模式介绍（了解）
创建型模式（5种）
工厂方法模式（Factory Method）：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
抽象工厂模式（Abstract Factory）：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
单例模式（Singleton）：确保一个类只有一个实例，并提供一个全局访问点。
建造者模式（Builder）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
原型模式（Prototype）：用原型实例指定创建对象的种类，并且通过复制这些原型来创建新的对象。
结构型模式（7种）
适配器模式（Adapter）：将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而无法一起工作的类可以一起工作。
装饰器模式（Decorator）：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰器模式相比生成子类更为灵活。
代理模式（Proxy）：为其他对象提供一个代理以控制对这个对象的访问。
外观模式（Facade）：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
桥接模式（Bridge）：将抽象部分与它的实现部分分离，使它们可以独立地变化。
组合模式（Composite）：将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。
享元模式（Flyweight）：运用共享技术有效地支持大量细粒度的对象。
行为型模式（11种）
策略模式（Strategy）：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。策略模式使得算法可以独立于使用它的客户而变化。
模板方法模式（Template Method）：定义一个操作中的算法的框架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
观察者模式（Observer）：定义对象之间的一对多依赖关系，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
迭代器模式（Iterator）：提供一种方法顺序访问一个聚合对象中各个元素，而又不需暴露该对象的内部表示。
责任链模式（Chain of Responsibility）：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
命令模式（Command）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。
状态模式（State）：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
访问者模式（Visitor）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
中介者模式（Mediator）：用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
解释器模式（Interpreter）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
5、责任链模式
责任链模式的设计目的是为了解耦请求发送者与多个接收者之间的关系。它通过将多个接收者组成一条链，并沿着这条链传递请求，直到有一个接收者处理请求，从而实现了灵活的请求处理机制。
在责任链模式中，处理请求的对象通常被称为处理器或链的节点。每个节点包含了处理请求的逻辑以及指向下一个节点的引用。当请求到达一个节点时，如果该节点无法处理请求，它会将请求转发给下一个节点，直到有一个节点处理请求或整个链都无法处理。
责任链模式在实际开发中有广泛的应用场景，例如：
过滤器链：在Web开发中，可以通过责任链模式实现过滤器链，例如Spring框架中的FilterChain。每个过滤器都有机会处理请求，直到最后一个过滤器完成处理。
日志记录器：日志系统中可以利用责任链模式将多个日志记录器组成一条链，以实现不同日志记录方式的灵活组合。
异常处理器：应用程序中可以使用责任链模式实现异常处理器的链式调用，以灵活地处理各种异常情况。
授权认证：系统中可以利用责任链模式实现授权认证的链式调用，以灵活地控制不同用户对系统的访问权限。
6、状态模式
状态模式允许对象在其内部状态发生变化时改变行为，使其看起来像是修改了其类结构。这通过将对象的行为封装在不同状态对象中实现，在运行时能够动态改变对象的状态，从而影响其行为。
实际应用中，状态模式有多种场景，如：
订单状态管理：订单状态包括未付款、已付款、已发货、已签收等。不同状态下，订单的行为也会有所不同。
游戏角色状态：游戏角色可能处于待机、行走、攻击、受伤等不同状态。不同状态下，角色表现出不同的行为。
音视频播放器：音视频播放器状态包括播放、暂停、停止、快进、快退等。不同状态下，播放器的行为也有所差异。
在实际应用中，状态模式通常需要与其他设计模式结合使用，如工厂模式、单例模式、策略模式等，以实现更灵活和高效的代码设计。这种组合能够提供更好的扩展性和维护性，使系统更易于理解和修改。
7、策略模式
策略模式是一种行为设计模式，它允许在运行时根据不同情况选择不同算法的实现。该模式将算法及其相应的行为封装在独立的类中，使得它们可以相互替换而不影响客户端的使用。策略模式遵循开闭原则，即可以在不修改现有客户端代码的情况下，动态地添加、删除或替换算法。
相较于使用if-else语句，策略模式具有以下优势：
易于扩展：策略模式方便地支持增加、删除或更换算法，只需添加新的策略类而无需修改原有代码。
更好的可读性：将复杂的条件语句分散到不同的策略类中，使代码更清晰、易于理解和维护。
避免大量条件判断：在if-else语句中，条件判断可能会变得复杂难以维护，而策略模式可以将条件判断分散到各个策略类中，简化代码。
提高代码复用性：将常用算法封装在策略类中，可以被多个客户端共享使用，提高代码的复用性。
在实际应用中，策略模式通常与工厂模式、模板方法模式等结合使用，以实现更灵活、可维护的代码设计。
8、观察者模式
观察者模式是一种行为设计模式，它建立了对象之间的一对多依赖关系。当一个对象的状态发生变化时，所有依赖于它的对象都会得到通知并自动更新，从而实现了松耦合。被观察者对象无需知道观察者的具体实现细节，只需通知它们即可。
观察者模式在许多应用场景中都具有广泛应用，特别是在需要处理对象之间松耦合、实时通知和更新的情况下。以下是观察者模式常见的应用场景：
发布-订阅系统： 观察者模式是发布-订阅模式的核心。发布者发布消息或事件时，所有订阅者都会收到通知并执行相应操作。
事件处理机制： 用于处理事件驱动的编程，事件触发时通知事件处理程序（观察者）执行相应操作。
实时数据更新： 在需要实时更新数据的应用中，将数据源与数据消费者连接起来。数据源变化时，观察者可以获取最新数据并进行处理。
库和框架： 许多编程库和框架使用观察者模式来支持插件和扩展。开发人员可以编写自定义观察者以响应库或框架中的事件或回调。
消息队列系统： 用于消息队列系统，生产者将消息发送到队列，而消费者作为观察者订阅队列接收和处理消息。
股票市场监测： 股票市场应用程序使用观察者模式监测股票价格变化，并通知投资者。
游戏开发： 用于处理各种游戏事件，如玩家输入、碰撞检测、角色状态变化等。
网络通信： 在网络应用中，观察者模式可用于实现即时通信系统，实现用户之间的消息传递。
9、代理模式
代理模式是一种结构设计模式，通过创建代理对象来控制对其他对象的访问。代理对象充当原始对象的接口，客户端通过代理对象间接地访问原始对象，并有机会在访问过程中添加额外的逻辑或控制。
代理模式的主要目的是引入代理对象，为原始对象提供一层间接访问方式，以实现对原始对象的控制、保护或增强。常见的应用场景包括：
远程代理： 在分布式系统中，代理模式可用于代理远程对象，隐藏了远程对象的实际实现细节，使客户端可以像访问本地对象一样访问远程对象。例如，Dubbo框架使用了代理模式的概念。
动态代理： 允许在运行时动态创建代理对象，并将方法调用动态分派到不同的处理器。通过Java的反射机制实现，可用于实现通用的代理逻辑，避免为每个被代理的类单独创建代理。Spring的AOP就是一个使用动态代理的典型例子。
缓存代理： 用于缓存原始对象的结果，以避免重复计算或访问资源。代理对象首先查询缓存，如果缓存中不存在，则访问真实对象。这种模式在需要优化访问性能的场景中很常见。
日志代理： 用于记录统一的日志信息，通过创建代理对象，在代理中进行日志记录和管理。这在需要对系统进行日志记录时非常有用。
异常代理： 用于处理系统中的统一异常机制或ERROR_CODE机制。通过创建一个统一的代理，可以在代理对象中捕捉和转换异常，实现异常的集中处理。
代理模式在以上场景中发挥重要作用，通过适当的代理对象，能够实现对原始对象的控制和增强，同时保持客户端对对象的透明性。
10、模版方法
模板方法模式是一种行为设计模式，其主要目的在于提高代码的复用性。在许多情况下，代码中可能存在一些共享的核心逻辑和一些需要定制的部分。模板方法模式通过将这些共享的部分定义在父类中，而将具体的实现交给子类，实现了对算法结构的保持稳定，同时允许子类根据需求灵活扩展或重写父类的方法。
通常情况下，模板方法模式与策略模式一起使用，因为在使用策略模式时，我们将具体的策略实现放置在策略服务中，而一些通用的逻辑部分仍然存在。通过模板方法模式，可以实现这些通用逻辑的复用，使得代码更加清晰和可维护。这种组合使用的方式能够充分利用两种设计模式的优势，提高系统的灵活性和可扩展性。

回答提示：是一种比较通俗的解释，比较好理解，如果‘参考答案’不太好记住，可以直接复习回答提示也可以。
1、Java中的集合类有哪些？如何分类的？(此问题基本不会被问到，但是要大体理解整个集合的内容，如果能记住此问题（灵活记住），面试集合的基础问题基本都可以回答)
回答提示：
List（列表）：List接口及其实现类用于存储一组有序的元素。元素可以重复，且可以通过索引访问。常见的List实现类有ArrayList、LinkedList等。ArrayList基于动态数组实现，访问元素速度快；LinkedList基于双向链表实现，插入和删除操作效率高。
Set（集合）：Set接口及其实现类用于存储一组无序且唯一的元素。Set不允许出现重复元素，因此常用于去重操作。常见的Set实现类有HashSet、TreeSet等。HashSet基于哈希表实现，元素存储无序；TreeSet基于红黑树实现，元素会按照自然顺序或者自定义顺序排序。
Queue（队列）：Queue接口及其实现类用于在元素之间定义一种先进先出（FIFO）的排序方式。常见的Queue实现类有LinkedList（也实现了List接口）、PriorityQueue等。LinkedList可以用作双端队列；PriorityQueue是一个基于优先级堆的无界队列，元素的排序方式可以通过比较器来定义。
Map（映射）：Map接口及其实现类用于存储键值对。键是唯一的，每个键都映射到一个值。常见的Map实现类有HashMap、TreeMap等。HashMap基于哈希表实现，键值对存储无序；TreeMap基于红黑树实现，键会按照自然顺序或者自定义顺序排序。
参考回答：
集合类存放于 Java.util 包中，主要有 3 种：set(集）、list(列表包含 Queue）和 map(映射)。
Collection：Collection 是集合 List、Set、Queue 的最基本的接口。
Iterator：迭代器，可以通过迭代器遍历集合中的数据
Map：是映射表的基础接口

一定要牢牢记住这张图，大多比较浅的面试题都是从这上面问的。 arrayList的扩容机制认为是1.5倍就可以了
2、那些集合是线程安全的？
参考回答：
Vector：一个线程安全的List实现，它的大部分方法都是同步的，因此可以在多线程环境中使用。不过，由于同步操作会带来性能开销，所以在不需要线程安全的场合，建议使用ArrayList。
Hashtable：一个线程安全的Map实现，它同样是同步的，可以在多线程环境中使用。与HashMap相比，Hashtable的性能可能稍差一些，因为同步操作会增加额外的开销。
Stack：一个线程安全的栈实现，它也是同步的，可以在多线程环境中使用。不过，由于栈这种数据结构的使用场景相对较少，所以在实际开发中可能会更少用到Stack。
ConcurrentHashMap：一个线程安全的 HashMap 实现。早期版本（JDK 1.7 及以前）使用分段锁（Segment Locking）技术来提升并发性能，JDK 1.8 以后则使用了更加细粒度的锁，如链表或红黑树节点上的 synchronized 和 CAS 操作。在多线程环境下，ConcurrentHashMap 的并发性能通常优于 Hashtable 以及通过 Collections.synchronizedMap(new HashMap＜＞()) 包装得到的同步 HashMap，因为后两者都是对整个 map 加锁，从而限制了并发能力，而 ConcurrentHashMap 则支持更高的并发访问。
CopyOnWriteArrayList：一个线程安全的List实现，它通过在写操作时复制整个数组来实现线程安全。这种策略适用于读多写少的场景，因为写操作会涉及到复制整个数组，所以性能开销较大。
3、ArrayList的扩容机制是什么？
回答提示：
初始容量：ArrayList在创建时默认有一个初始容量，通常是10（但在某些版本或实现中可能有所不同）。
扩容触发：当向ArrayList中添加元素，且当前元素数量达到容量上限时，就会触发扩容操作。
扩容策略：ArrayList的扩容策略是增长大约50%的容量。
数组复制：扩容过程中，ArrayList会创建一个新的、更大容量的数组，并将原有数组中的所有元素复制到新数组中。
参考回答：
ArrayList的扩容机制是这样的：当向ArrayList中添加元素，而当前数组容量不足以容纳更多元素时，ArrayList会自动进行扩容。具体来说，它会创建一个新的数组，新数组的长度通常是当前数组长度的1.5倍（也就是增长50%，但这个值不是固定的，不同的JVM实现可能有所不同，有的是直接扩容为原来的两倍）。然后，ArrayList会将当前数组中的所有元素复制到新数组中，并将新数组设置为当前数组。这样，ArrayList就拥有了更大的容量，可以继续添加更多元素。
4、ArrayList和linkedList的区别？
回答提示：
内部实现：ArrayList是基于动态数组实现的，元素在内存中连续存储；而LinkedList则是基于双向链表实现，元素通过指针相互连接。
随机访问：ArrayList支持快速随机访问，时间复杂度为O(1)；LinkedList则需要遍历，时间复杂度为O(n)。
内存占用：LinkedList每个节点除了存储数据外，还需要存储指向前一个和后一个节点的指针，因此比ArrayList更占内存。
使用场景：ArrayList适用于需要频繁进行随机访问的场景；而LinkedList则更适用于需要频繁进行插入和删除操作的场景。
参考回答：
ArrayList：基于动态数组，连续内存存储，适合下标访问（随机访问），扩容机制：因为数组长度固定，超出长度存数据时需要新建数组，然后将老数组的数据拷贝到新数组，如果不是尾部插入数据还会涉及到元素的移动（往后复制一份，插入新元素），使用尾插法并指定初始容量可以极大提升性能、甚至超过linkedList（需要创建大量的node对象）
LinkedList：基于链表，可以存储在分散的内存中，适合做数据插入及删除操作，不适合查询：需要逐一遍历
遍历LinkedList必须使用iterator不能使用for循环，因为每次for循环体内通过get(i)取得某一元素时都需要对list重新进行遍历，性能消耗极大。另外不要试图使用indexOf等返回元素索引，并利用其进行遍历，使用indexlOf对list进行了遍历，当结果为空时会遍历整个列表。
5、HashMap和HashTable有什么区别？
回答提示：
线程安全性：HashMap是非线程安全的，而HashTable是线程安全的。HashTable通过synchronized关键字实现同步，但可能导致性能下降。
null值处理：HashMap允许null作为键和值，而HashTable不允许。
性能：由于HashMap不需要考虑线程同步，通常性能更高。
参考回答：
区别 ：
线程安全性
HashMap方法没有synchronized修饰，线程非安全，HashTable线程安全；
空键和空值：
HashMap允许key和value为null，而HashTable不允许
历史遗留：（了解）
Hashtable 是 Java 1.0 中的遗留类，虽然仍然可以使用，但通常建议使用 HashMap，并结合 java.util.concurrent 包中的现代并发类来处理多线程问题。
HashMap 是在 Java 2 中引入的，设计更现代化，使用也更加灵活。
迭代器：(了解)
HashMap 使用的是快速失败（fail-fast）的迭代器，如果在创建迭代器后对集合进行了结构上的修改（除了使用迭代器自身的 remove 方法外），迭代器会抛出 ConcurrentModificationException。
Hashtable 使用的是枚举（Enumeration），不是快速失败的迭代器。
性能：（了解）
在没有线程安全需求的场景中，HashMap 通常比 Hashtable 性能更高，因为它没有同步的开销。
6、HashMap底层实现原理是什么？
参考回答：
JAVA7 实现：数组+链表实现

大方向上，HashMap 里面是一个数组，然后数组中每个元素是一个单向链表。上图中，每个绿色的实体是嵌套类 Entry 的实例，Entry 包含四个属性：key, value, hash 值和用于单向链表的 next。
capacity：当前数组容量，始终保持 2^n，可以扩容，扩容后数组大小为当前的 2 倍。
loadFactor：负载因子，默认为 0.75。
threshold：扩容的阈值，等于 capacity * loadFactor
JAVA8 实现：数组+红黑树实现
Java8 对 HashMap 进行了一些修改，最大的不同就是利用了红黑树，所以其由 数组+链表+红黑树 组成。
根据 Java7 HashMap 的介绍，我们知道，查找的时候，根据 hash 值我们能够快速定位到数组的具体下标，但是之后的话，需要顺着链表一个个比较下去才能找到我们需要的，时间复杂度取决于链表的长度，为 O(n)。为了降低这部分的开销，在 Java8 中，当链表中的元素大于等于 8 个并且数组长度大于等于64以后，会将链表转换为红黑树，在这些位置进行查找的时候可以降低时间复杂度为 O(logN)。

HashMap底层原理面试大公司可能hashMap问的深一些，根据自己实际情况复习
7、ConcurrentHashMap原理？
参考回答：
分段：ConcurrentHashMap 和 HashMap 思路是差不多的，但是因为它支持并发操作，所以要复杂一 些。整个 ConcurrentHashMap 由一个个 Segment 组成，Segment 代表”部分“或”一段“的 意思，所以很多地方都会将其描述为分段锁。注意，行文中，我很多地方用了“槽”来代表一个 segment。
线程安全：ConcurrentHashMap 是一个 Segment 数组，Segment 通过继承ReentrantLock 来进行加锁，所以每次需要加锁的操作锁住的是一个 segment，这样只要保证每个 Segment 是线程安全的，也就实现了全局的线程安全。

并行（默认16）：concurrencyLevel：并行级别、并发数、Segment 数，怎么翻译不重要，理解它。默认是 16， 也就是说 ConcurrentHashMap 有 16 个 Segments，所以理论上，这个时候，最多可以同时支 持 16 个线程并发写，只要它们的操作分别分布在不同的 Segment 上。这个值可以在初始化的时 候设置为其他值，但是一旦初始化以后，它是不可以扩容的。再具体到每个 Segment 内部，其实 每个 Segment 很像之前介绍的 HashMap，不过它要保证线程安全，所以处理起来要麻烦些。
Java8 实现 （引入了红黑树）

8、HashMap 和 Hashtable 的区别？
参考回答：
线程是否安全：HashMap 是非线程安全的，Hashtable 是线程安全的,因为 Hashtable 内部的方法基本都经过synchronized 修饰。（如果你要保证线程安全的话就使用 ConcurrentHashMap 吧！）；
效率： 因为线程安全的问题，HashMap 要比 Hashtable 效率高一点。另外，Hashtable 基本被淘汰，不要在代码中使用它；
对 Null key 和 Null value 的支持：HashMap 可以存储 null 的 key 和 value，但 null 作为键只能有一个，null 作为值可以有多个；Hashtable 不允许有 null 键和 null 值，否则会抛出 NullPointerException。
初始容量大小和每次扩充容量大小的不同： ① 创建时如果不指定容量初始值，Hashtable 默认的初始大小为 11，之后每次扩充，容量变为原来的 2n+1。HashMap 默认的初始化大小为 16。之后每次扩充，容量变为原来的 2 倍。② 创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而 HashMap 会将其扩充为 2 的幂次方大小（HashMap 中的tableSizeFor()方法保证，下面给出了源代码）。也就是说 HashMap 总是使用 2 的幂作为哈希表的大小,后面会介绍到为什么是 2 的幂次方。
底层数据结构： JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为 8）时，将链表转化为红黑树（将链表转换成红黑树前会判断，如果当前数组的长度小于 64，那么会选择先进行数组扩容，而不是转换为红黑树），以减少搜索时间（后文中我会结合源码对这一过程进行分析）。
9、HashMap 与 ConcurrentHashMap 的异同？
参考回答：
它们底层都是哈希表结构，核心功能都是存键值对，比如计算哈希定位桶、处理哈希冲突这些基础逻辑是一样的。但关键差异在于线程安全的设计。
先说HashMap，它最大的特点是不保证线程安全。比如多线程同时put数据，可能会导致数据覆盖，甚至Java7之前扩容时可能出现死循环。而且它允许key和value为null，平时开发中要注意避免空指针问题。
而ConcurrentHashMap是专门为高并发设计的。Java8之后它的线程安全实现很巧妙——通过CAS + synchronized分层控制锁粒度：
无锁化的CAS操作：
当插入数据时，如果目标哈希桶是空的，直接用CAS尝试写入第一个节点，无需加锁。
统计元素大小时，采用类似LongAdder的分段CAS计数，减少竞争。
这类无锁操作在低并发场景下性能极高，几乎无额外开销。
细粒度的synchronized锁：
当哈希冲突发生（桶非空）时，才用synchronized锁住链表或红黑树的头节点。
比如两个线程操作不同的桶，完全不会阻塞，并发度取决于桶的数量。
由于锁的粒度细化到单个桶，比Java7的分段锁更灵活。
这种设计的关键在于：先尝试无锁的CAS，失败后再加锁。比如插入数据时，如果CAS发现桶已被其他线程初始化，则转为锁住头节点操作链表或红黑树。这种分层策略大幅减少了直接加锁的概率。
不过ConcurrentHashMap有个限制：不允许存null值。这是因为CAS本身需要明确的预期值（比如判断桶是否为空时，预期值必须是null），如果允许存null，会导致CAS语义歧义（无法区分“桶未被初始化”和“value本来就是null”）。
实际使用中的注意点：
迭代器行为不同：HashMap的迭代器是“快速失败”的，一旦遍历时发现被修改会直接抛异常；而ConcurrentHashMap的迭代器是“弱一致性”的，遍历时可能看不到其他线程的最新修改，但不会报错。
组合操作仍需加锁：比如先检查containsKey(key)再put(key)，即使使用ConcurrentHashMap，这两个操作的组合也不是原子的，需要外层同步。
选择建议：
单线程或明确无并发：用HashMap（性能最优）
多线程环境：直接用ConcurrentHashMap。虽然早期开发会觉得“可能竞争不激烈”，但现代服务器都是多核，ConcurrentHashMap的CAS在无竞争时几乎零损耗，而有竞争时也比Hashtable的全局锁高效得多。

这里有最全的Java企业面试实战内容，内容涵盖Java核心知识、项目经验、技术难题应对等方方面面。这不仅仅是面试经验，更是一次次职场历练的总结。给即将准备面试的人一个参考及复习方向

🎤 录音实录，身临其境！

我收集了真实企业面试录音，通过录音，仿佛置身于真实的面试现场，听到他们的声音，感受他们的紧张与从容。这是一场真实的Java实战经验分享，让你随时随地都能感受到真实面试的情景。

大厂面试录音

美团一面，我不怕千万人阻挡，只怕自己投降。

【滴滴一面】真实现场大厂面试

【滴滴二面】来听听大厂是如何在项目上提问！

(美团)想在大城市发展的五年工作经验程序员的面试经历！

滴滴一面。坐标北京，关于RocketMQ问的还是比较深的

面试技巧系列

面试官问我上一家公司离职原因怎么办？

不知道如何面试怎么办，面试之前应该注意什么？

秋招写简历，并没有任何工作经验，该怎么去充实？

一年多经验。是说出了什么，但又好像没有。

一年经验。之前开发项目经验符合面试公司需求。

一年经验。简历跟职位不匹配，最后g了。

一年半经验。呃....自己看吧。

大家觉得这个有一年工作经验嘛？

一年经验。之前开发项目经验符合面试公司需求。

两年工作经验

两年经验。这样一面都过不了吧。

两年经验面试记录。

两年经验。期望11K，如果你面试，你会给嘛？

2年经验 应聘者：我就是写代码的，没做过需求设计。

还是2年经验。可惜了！

今天的你一定会“感激”昨天“努力”的你！！！

2年经验，面试官很中意。

三年工作经验

你这也太老实了吧！

平安项目组1面。五年的工作经验，三年的开发经验。

三年经验，12K的期望薪资。

没学过这课不行？！gg？

三年以上工作经验

Java四年开发经验

4年经验面试百信。项目及基础知识都有被问到！

想在大城市发展的五年工作经验程序员的面试经历！

面试过程中一定要自信！但不能自负！

1、如何进行压力测试。

2、数据库里面数据类型是bigint（这个XXX我不记得是哪个数据类型了） ，idea里面数据类型是LONG，传到前端会丢失最后三位数，怎么办？

3、git管理怎么做？

4、mq引入到项目中不会很大吗？使用mq难不难？

5、家长是不是都得装这个APP？

6、Redis一般用作缓存来查？

20230405面式问题（3年工作经验）

1、使用RocketMQ导入表格数据到数据库，不用不可以吗， 项目使用 RocketMQ 完成名单的导入，提高了系统的工作效率怎么提高的？

2、Redis的hash和Java的HashMap区别。

3、为什么HashMap长度是2的幂次方，还知道哪些数据结构，队列有哪些队列。

4、Redis分布式锁Redis挂掉怎么办，项目有哪些服务，在哪个服务开发，网关作用。

5、mybatis一二级缓存，操作SQL的对象。

6、SpringBoot启动过程，数据库连接池是什么，扮演角色。

7、项目中请求流转过程，IOC容器工作过程。

9、使用 RocketMQ+分布式加锁完成名单的分配怎么做的。

10、使用 Redis 缓存名单分配的信息业务流程，前端技术，后端交互数据类型，接收JSON数据用什么注解等等。

20230407面式问题（3年工作经验）

1、rocketmq名单导入怎么做的。

2、主表和临时表具体是怎么合并的，他们怎么关联的。

3、rocketmq分布式锁名单分配具体怎么做的。

4、redis怎么实现加锁动作，缓存名单信息的原因，怎么实现的。

5、数据库数据什么时候加载缓存的。

6、key会不会过期，Redis和数据库谁先写，怎么保证一致性。

7、rocketmq分布式事务业务场景。

20230428面式问题（1年工作经验）

1、客户数据的导入中数据是从哪里来的，用什么进行导入，数据支持的最大导入数量是多少？

2、为什么要采用异步导入，RocketMQ有没有替代方案？

3、导入的这个过程中使用的技术是自己按照任务进行的技术选择完成功能开发吗？

20230502面式问题（2年工作经验，北京神州泰岳）

1、他说责任描述上写的是测试及测试文档的编写，问我是不是做测试的？

2、登陆的时候，前端的手机号、验证码这些敏感信息是怎么处理的，后端做了哪些检验。

3、创建一个组合索引abc,查询条件是bc的话，这个索引可以起效吗。

4、spring事物是怎么使用的，有哪几种。

5、redis怎么使用，数据类型有哪些。

20230504面式问题（1年工作经验）

1、做个自我介绍？

2、说一下你在项目中做了什么？

3、想问下细节上的东西，我不太懂为什么延时任务要用Netty时间轮，一般用RocketMQ中的延时任务不就行了吗？你为什么要选型选这个呢？

4、你有了解过RocketMQ的延迟消息吗？是怎么实现的？

5、跟我讲讲Netty时间轮什么方面让你选择了它？它有什么优点，什么缺点？

6、RocketMQ的底层数据结构了解过吗？

7、简历上的AOP实现延时任务失败恢复为可执行，完成任务自动删除，具体解释下？

8、我不太明白这是一个比较明确，有针对性的任务，为什么要使用AOP，而不是直接在代码中处理？这样不会增加代码可读性上的负担吗？如果是一个统一的有共性的事情我觉得AOP是比较适合的，但这种情况使用我觉得不太适合。

9、我来问一些基础的问题吧，线程池的参数，线程池的处理流程？

10、你说的这个外包工人也就是临时线程没有任务了，会被削减掉吗

11、如果核心员工（核心线程）没有工作了，会被开除掉吗？

12、我再问你个场景，比如说我核心员工有3个，线程池我从无到有，来了一个任务交给员工1，员工1已经把这个任务做完了，然后员工1处于一个等待的状态，这个时候我又来了一个任务，会交给谁？

13、ThreadLocal了解过吗

14、使用ThreadLocal的过程中有什么要注意的点？

15、它可以线程穿透吗？

16、那你知道怎么做可以让他们穿透吗？

17、mysql用过吗？讲讲mvcc

18、mvcc是怎么区别这两种隔离级别的？（读已提交 和 可重复读）

19、除了undolog 你还知道mysql其他的log吗。

20、我现在有一个场景，我们项目中经常会出现全表查询的一个场景，某一个条件没？上（没听清）导致我查询了全表 ，我想做全表查询的一个拦截，有一个附加条件，表里会有软删除isDeleted这种字段，只有这个字段的查询我也给他标记成全表查询，这两种情况我希望给他拦截掉，进行异常处理。我想知道你的一个思路。

21、那Mybatis的拦截器你知道吗？

22、你有什么想问的吗？

20230505面式问题（2年工作经验）

1、项目中用到rabbitmq主要是为了解决什么问题 为什么不选择其他

2、数据放到缓存里redis放置多久

3、测试环境有问题怎么处理

4、项目中的事物怎么处理的

5、项目中的有用到多线程嘛

6、explain执行计划有哪几种方式

7、风险画像是实时生成的嘛

9、项目中为什么选用redis作为缓存工具 为什么不选用其他的

10、项目中用到的管理工具

11、有没有遇到因为数据量过大索引失效

12、什么情况下会走全表扫描不走索引 怎么处理

20230507面式问题（3年工作经验）

1、用SpringCloud来搭建一个完整的服务你能搭建起来吗？说一下你的思路

2、GateWay网关鉴权怎么做？

3、说一下个人对Nacos的了解

4、让你写一个IOC你会写吗？说一下你的思路

5、你觉得IOC核心提供了哪些功能？

6、你常用的类注解器有哪些？

7、@Service和@Componet有什么区别？

8、@Autowire跟@Resource有什么区别？

9、你对AOP是怎么理解的？

10、你觉得AOP是怎么实现的？

11、你平时有没有用Context上下文？

12、我有个商品，我要防止超卖要怎么写SQL？

13、用Redis怎么防止超卖

14、MySQL的锁机制你怎么了解？

15、RabbitMQ的同步消息和异步消息你怎么发？

16、你是怎么理解RabbitMQ的同步消息跟异步消息？

17、你用Redis怎么写分布式锁？就是简单的setnx？你这样不会出问题？

18、我现在要设计一个SKU表，你要怎么设计？

20230523面试问题（3年工作经验）

1、举个需求讨论的例子，结合项目来说

2、在需求讨论中有没有哪个环节或过程意见分歧比较大

3、跟项目经理对进度具体过程

4、es中的term，terms区别

5、对自己未来的规划

6、离职原因

7、具体的服务器部署在哪

8、你觉得你想在哪些领域内深耕

9、线上系统出现问题(用户反映慢/卡)，讲一讲实际例子，自己怎么排查，解决的

20230525面试问题（2年工作经验）

1、Spring的三级缓存

2、Redis为什么要把所有的数据都存在缓存里

3、Eurka的保护机制

20230528面式问题（实习6个月）

1、实习收获？

2、实习过程遇到的问题，是怎么解决的？

3、项目的数据量有多大？

4、数据是怎么获得的？

5、es有几个分片几个副本？

20230601面式问题（2年工作经验，深圳市网新新思软件有限公司）

1、线下运营的实体也是自己公司的产品吗。

2、使用spring定时器为什么要2个小时查询一次数据库，是数据太多还是计算压力太大了，为什么不做成实时的，怎么考量做成2个小时的，有哪些评估方案。

3、模糊查询直接是用mongodb查询的吗。

4、为什么选择mongo记录用户的行为，是因为数据量很大吗。

20230612面试问题（2年工作经验）

1、项目中的内外部数据是怎么整合的？

2、规则是怎么配置的，怎么通过信号看是不是命中了规则

3、信号的人工审批流程是怎样的？怎么样下发的？

4、项目中有没有遇到业务上特别难的实现的逻辑？

20230620面试问题（2年工作经验佳都科技的子公司上海方纬）

1、单个表的数据量有多大？

2、内存溢出后，jvm的工具有哪些？

3、服务的启动？

4、数据的切片？

5、mysql加索引的数据大小？

6、什么情况下内存溢出？

7、会配置es吗？

8、负载均衡怎么做的？

9、jar有没有加密？

10、加密算法有了解过吗？

20230628面试问题（2年多工作经验，深圳商信通 ）

1、Gateway如何实现动态路由

2、Jwt令牌负载添加信息如何操作

3、Docker、k8s、jekins

4、如何对字符串数组去重（只回答了一种，面试官明显不满意）

5、Feign实际是什么

6、项目用到的springcloud组件

7、项目是你搭建的吗，如果让你搭建spring cloud框架要多久

8、Callable是如何实现有返回值的

20230629一、二面试问题（6年多经验）

一面

1、copyonwritearraylist ，你知道吗

2、java中 常用的锁有哪些

4、为什么非公平锁效率会高一些

5、预约会议，定时任务是扫码数据库吗，定时任务的设置频率是多少

6、扫描数据库，是通过定时任务扫描，还是通过消息扫描（半小时扫描一次会议，看有哪些符合条件的会议）

7、xxl-job怎么去终止一个任务呢

8、怎么做到消息的唯一性，重复消费的解决方式（会需要将唯一性的ID存起来吗）

9、消息队列的异常时怎么发现的，大量消息堆积是怎么发现的，监控发现吗

10、处理堆积消息的过程中，还在产生的消息怎么处理

11、服务之间调用，如果有异常怎么处理，闪断的情况怎么处理（中间有波动，第一次没有连上，第二次再连上了）

12、服务之间怎么调用，需要用什么注解

13、项目中的高可用、高并发怎么用到的

14、创建会议时的多线程问题（多个人同时创建同一个会议室），会议室比较，时间比较，有没有事务的回滚的发生

15、后台会有线程，去判断它的网络状态吗，网络断了，会有重连的机制吗

16、跟Zoom的通信是通过哪一种协议去做的（网络方面的知识，Http、https、还是tcp、udp）

17、数据库做主从，还是redis做主从

18、redis主从全量复制 和 增量复制，怎么实现

19、分布式锁，唯一值是当时临时加的，还是之前定义好的

二面

1、一天会有多少业务数据

2、数据库设计表会遵循什么样的原则和方法

3、redis的分布式锁怎么实现，（执行任务的时候超过了锁过期的时间，怎么解决，锁会不会被其他的任务抢到，或者处理人出现异常了，导致锁不能释放，这样其他人也抢不到锁了）

4、xxl-job调度工具，采用哪一种方式去实现配置任务的，调度的client是什么形式，是程序控制，还是远程调用

5、springboot在项目启动的时候，会去做哪些事情

6、SpringBoot或者Mybatis，有了解过底层源码实现吗

7、redis集群，缓存雪崩、缓存击穿这些内容有在项目中实现吗

8、redis一致性问题（redis的一致性问题，和MySQL数据库的一致性）

20230629面试问题（实习 苏州海管家）

1.项目主要负责了哪些模块

2.登录模块不是二次开发的吗，是你重新编写的吗

3.问答模块做了哪些功能

4.排行榜展示的权重值（浏览量、评论量、点赞量）的计算公式

5.消息模块怎么通知用户的

6.三十分钟最后一秒进行支付，这种并发情况会怎么办

7.如何实现爱奇艺类似的只能登录三个用户

8.为什么使用MongoDB记录用户行为不用mysql

9.存放到MongoDB的数据结构大概长什么样，记录哪些关键的字段

10.redis的结构是怎么存的，key，value

11.制造执行系统的难点

12.数据分析怎么做的

欢迎点击查看学员的快乐：🎓 学无止境，梦想起航！

砥砺前行，汗水浇灌，终于，我们的学员们迎来了人生中最为辉煌的时刻，获得了令人翘首以待的 Offer。让我们一同欢庆，为他们的奋斗与付出点赞。

🚀 Offer 闪耀登场，梦想翱翔

在学习的征途上，他们挑战自我，攀登技术高峰。如今，他们的努力终于得到了最美的回报。这一份 Offer，不仅仅是一纸合同，更是梦想起航的翅膀，带领他们飞向事业的巅峰。

🌐 世界等待，岗位静候

这份 Offer 不仅是一份工作邀约，更是通向未来的门票。他们将踏上职场的征程，探索技术的无限可能。无论是编码的乐章，还是团队的协奏曲，他们都将在职场的舞台上展现才华，书写属于自己的传奇。

🛠️ 技术之光，闪耀全球

这份 Offer 背后是技术的光芒，是知识的力量。他们将在职业生涯中，用 Java 的精湛技艺，为世界贡献自己的一份力量。从代码的层层叠叠到系统的优化创新，他们将点亮未来的数字时代。

🤝 共筑辉煌，团队同行

这不仅是个人的胜利，更是团队的荣耀。在这个特别的时刻，我们齐聚一堂，共同见证这份 Offer 的诞生。他们将与团队一同携手前行，共同创造未来的辉煌。

🎉 祝贺每一位 Offer 获得者

在这充满喜悦的时刻，让我们为每一位 Offer 获得者献上最热烈的祝福。愿你们在职场的征途上，勇攀高峰，创造更多的成功与辉煌。Offer 是起点，更是新生活的开始。未来的道路上，愿你们的步履坚定，梦想翱翔。

训练营能提供什么？

• 1V1 摸底评估：先了解你的基础、项目、工作年限和求职目标，再定制学习和面试计划。
• 知识体系辅导：围绕 Java 基础、JVM、MySQL、Spring 全家桶、Redis、MQ、设计模式、算法等高频面试内容进行系统梳理。
• 项目经验包装与表达：匹配合适的企业级真实项目思路，重点讲清楚业务流程、技术方案、亮点难点和项目表达方式。
• 简历优化服务：根据目标岗位做个性化简历修改，持续调整到简历反馈明显提升。
• 模拟面试与复盘：通过多轮技术面、项目面模拟训练，发现问题、及时复盘、持续修正。
• 投递与 offer 指导：包含投递策略、HR 沟通建议、面试复盘和 offer 决策辅助。

辅导内容

1. 建立 1V1 辅导沟通机制，完成能力测评和目标拆解。
2. 制定每日/每周学习与面试准备计划，并持续跟进执行。
3. 系统梳理八股知识点，帮助你建立完整的面试知识框架。
4. 结合个人情况匹配项目内容，强化项目亮点、难点和技术细节表达。
5. 优化简历、自我介绍、项目介绍和常见问题回答模板。
6. 进行模拟面试、面后复盘、问题汇总和针对性强化。
7. 提供投递节奏、沟通策略和拿到 offer 后的选择建议。

服务流程

1. 初步沟通：了解你的学历、工作经验、技术基础和求职方向。
2. 评估定位：结合当前水平与目标岗位，制定专属辅导方案。
3. 知识辅导：按计划推进基础知识、面试题和重点专题训练。
4. 项目打磨：梳理项目背景、业务流程、技术方案、难点亮点和问答细节。
5. 简历优化：完善简历内容，突出优势，提高简历通过率。
6. 模拟面试：开展技术面、项目面、HR 面模拟并持续复盘。
7. 投递跟进：结合反馈动态调整投递策略和面试准备重点。
8. 拿到 offer：协助分析 offer 情况，帮助你更稳地完成入职决策。

流程图

套餐内容和服务流程如下：

适合哪些同学？

• 想冲刺春招、秋招的应届生
• 项目表达薄弱、面试回答没重点的同学
• 工作几年后准备跳槽，但缺少系统复习节奏的开发者
• 自学或培训后想尽快提升面试通过率的求职者

如果你想报名，或者还有什么需要咨询的，可以加枫哥微信：itfdz666，加的时候备注：报名。

坚持一件事本身就不容易，如果坚持做一件事八年了那就更难了，各位小伙伴扪心自问，6-7年前多少人还是小白或者才开始学习，同行当中很多人都是才上大学甚至还没上大学吧，抖音上目前已知的有一些出来做辅导的是我几年前辅导过的，能把一件事坚持做七年，这样的人难道不值得你信任和让他们给你辅导面试吗？后面只要不退休互联网行业不崩，我们一直都在。

2018年（八年风雨，不忘初心）

慢慢的，除了贴吧写帖子，也开始CSDN和其他技术平台写技术文章了，写技术文章不仅是对自己的一个沉淀，也能帮助到更多的人学习技术，在一次一次辅导中得到小伙伴的肯定：“老哥还稳的”、“很强”、“真的很开心”。枫哥找到了做这个事情的意义！

2019年辅导记录：

一晃做辅导两年了，IT枫斗者团队迎来了新的技术老师，也是我们罗老师，同年我们推出了面试辅导套餐、简历定制套餐，为了让学员交易更有保障，我们也专门开了淘宝店。那一年几乎每个月都有辅助进大厂的，枫哥还内推了一个来自己公司的。

2020年辅导记录：

这一年是特殊的一年，也是IT枫斗者团队的一个转折点，因为封控很多小伙伴在家都很无聊，但是IT行业影响最小的因为可以远程办公，也就是那一年在线教育火了，这一年枫哥新增了私教带徒套餐，上线了专门为学徒学习的在线教育网站，团队也迎来了青木老师、淡漠老师，我们的大家庭又壮大了。

2021年辅导记录：

正所谓人红是非多，更何况我们还不是很火，在这一年有一些同行冒充枫哥的小号去坑人，这个时候枫哥意识到了要保护自己的权益也要保护相信自己的学员了，于是注册了商标，同时所有技术老师头像都是“IT枫斗者”+后缀，这样辅助记录截图出来也不怕别人盗图了。

2022年辅导记录：

这一年IT枫斗者团队迎来了丙丙老师的加入，同时这一年想要进国企和事业单位的特别多，还有想要考证的，很多来咨询枫哥的，为了这个枫哥亲自把国企和事业单位的面试和笔试都经历过一遍。同时也去考了计算机的软考的高级证书，还专门写了文章分享如何考证并且通过证书去领取人才补贴10万元。

2023年辅导记录：

现在看来这年是一个互联网行业的转折点， 2023年真的感受到了互联网的寒冬，在这一年之前几乎很多简历投出去面试很多，甚至发现外包都开始挑剔了。大厂和自研要求更是严格。同年韩清宗老师也加入了团队。在这一年枫哥做出了一个让大家都很吃惊决定，直接辞职了，全职开始做面试辅导，枫哥说现在行情差有很多的人需要他，他要对得起信任他的粉丝们，这一年开始了直播，也就是直播才发现抖音我们做的太晚了，有一些同行都已经十几万粉丝了，你要知道枫哥做辅导的时候那些同行还在上大学，通过短视频一包装摇身一变就是某大厂出来的了，不过他们确实抓住了风口。

2024年辅导记录：

每天都有很多人找枫哥抱怨，网上充满了负能量和大环境不好的声音，枫哥决定要做一些力所能及的事情了，专门做一些心里辅导，鼓励学员调整好心态，行情不好使面向大家，不是针对某一个人，只要准备好还是能找到工作的。就跟高考试卷难一样，大家都难，所以要做好更充分的准备。这一年我们的IT枫斗者-彬哥，加入了我们的团队。

2025年辅导记录：

八年风雨，不忘初心，我们一直都在，我们的团队也一直在壮大。今年我们团队又迎来了新的技术老师，2025年我们团队是创建以来最强阵容，大厂经验几乎是标配，也是今年我们把枫哥工作九年以来的面试超神之路资料直接开源了。2025年才过去一半，我们辅导了最高薪资月薪38K，我们辅导了多个成人学历找到工作，甚至还有高中毕业的也找到了（这个是真的不容易，要付出常人三倍努力不止）。截图到2025年5月份数据，IT枫斗者团队2025年一共辅导了91个学员，其中86个收到了offer，就业率达到百分之九十六，96%，在当下这个环境下能达到这个就业率，技术老师是下了很大功夫的。

2026年辅导记录：

2026年，我们持续强化“一对一诊断 + 面试复盘 + 项目表达优化”的陪跑体系，帮助更多同学在复杂行情下拿到更稳的面试结果。

# 一年Java开发，本科，拿到华为od录用18k

• 工作年限：1.5年
• 学历：本科
• 初始预期薪资：13k
• 到手薪资：18k
• 介绍：学员在系统准备后顺利通过面试，offer 审批落地快，最终薪资较预期明显提升并顺利入职，过程细节见下方截图与说明。

# 逆袭大厂手撕算法，拿下滴滴offer入职34k

• 工作年限：6年
• 学历：211本科
• 初始预期薪资：29-30k
• 到手薪资：34k
• 介绍：围绕高并发与项目难点做了针对性梳理，面试节奏稳定推进并快速拿到结果，最终薪资高于预期区间，关键沟通记录见下方截图。

# 一年工作经验，本科，没有项目可以面试，最终拿下5个offer，总结出5个面经

• 工作年限：一年
• 学历：本科
• 初始预期薪资：10K
• 到手薪资：9K、10K、11K、10.5K、12k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 学历差？成人大专逆袭税后14.5K的offer已经成功入职！

• 工作年限：1年
• 学历：成人大专
• 初始预期薪资：7-9K
• 到手薪资：14.5K
• 介绍：针对学历门槛与面试信心不足的问题，先补齐 Java 核心与项目表达，再进行高频题和模拟面试强化，最终从 7-9K 预期提升到税后 14.5K 并顺利入职，完整过程见下方记录。

很多小伙伴觉得学历不好，没有什么面试机会，很难找到工作，确实现在学历不高，没有以前那么好找了，以前随便包装一下也能混进外包，现在难多了！

难，并不代表一点机会都没有，针对学历不占优势的，也非常想进入这一行一定要做好充分准备，从技术栈和项目经验上下功夫，突出你个人的能力！

同时入行以后，再提升你的学历，有经验以后，学历也不再是你的绊脚石了。

# 硕士应届生秋招，拿到深信服19k*15薪，年终0-6个月，600餐补

• 工作年限：0-1年
• 学历：硕士
• 初始预期薪资：18K*15薪
• 到手薪资：19k*15薪+年终0-6个月+600/月餐补
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 工作好几年薪资涨幅非常低，想要跳槽又怕没准备好，没有好的项目经验？

• 工作年限：3年
• 学历：本科
• 初始预期薪资：15-18K
• 到手薪资：18K
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

​ 在一家外包或者普通公司干了好几年，薪资涨幅非常低，但是自己几年技术栈又没有大的提升，又好久没有面试过了，感觉项目拿不出手，面试题、八股文、面试技巧、项目经验都不知道怎么弄！！！

​ 下面几个小伙伴都已经成功跳出舒适圈，拿到想要的offer！

经朋友介绍加入辅导后，系统梳理技术栈与项目表达，面试节奏明显提升，最终拿到年薪30W。

# 零基础自学，第一个offer：坐标青岛，年包24-25万一年。第二个offer：坐标北京，15.5*13薪，公积金和其他福利另算。

• 工作年限：0年起步
• 学历：普本
• 初始预期薪资：8-10K
• 到手薪资：年包24-25万一年

情况介绍：24年研究生毕业，之前自己去秋招一直各种不顺利，然后找到我们，原计划冲击一下秋招末班车，如果没有找到那就春招继续，所幸功夫不负有心人，在技术老师和小伙伴积极付出下拿到了两个offer。

# 从只会基础到拿下大厂度小满15*15k的offer，学员觉得是劝退价。。

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：15k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

情况说明：大四在校生，学校还不错，就是基础比较薄弱，只会一些java基础，连框架都没有学完，我们给定制了秋招训练营计划，赶上秋招的末班车，面试的期间也是非常坎坷，被好几家公司拒了，也是她的坚持不懈，最终收到度小满的offer，薪资15k*15薪！

# 九年开发经验，从别人那里报名一万多三个月后，简历还是狗不理，在b站上找到我们花了在别人那里的五分之一价格，经过辅导，拿到外企16K*14薪，朝九晚六双休，不加班

• 工作年限：九年
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：16K*14薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 函授本科，培训，半年多Java开发工作经验，西安拿下白菜价10k 朝九晚六双休

• 工作年限：0.5年+
• 学历：函授本科
• 初始预期薪资：未披露
• 到手薪资：10k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 民办本科非计算机自学转行拿到15k*14的offer

• 工作年限：未披露
• 学历：民办本科
• 初始预期薪资：未披露
• 到手薪资：15k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

情况说明：2019年民办本科毕业，油气储运工程专业，之前一直做销售，去年2022年的时候自学java，然后找了一个多月没有找到，通过朋友介绍找到我，然后辅助他入行，由于自学的底子比较弱，找到的一个10.5k的offer，在里面积累一年经验了，今年2023年想跳槽又找到我们，然后辅助找到一个15k*14的offer！

# 坐标深圳：三个offer，普通二本生物自学

• 工作年限：未披露
• 学历：普通二本
• 初始预期薪资：未披露
• 到手薪资：未披露
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

情况说明：2020年二本生物专业毕业，自学的，自己写的简历投了三四百份简历就两个面试，答的都不是很好，项目经验是最大的痛点，没有真实项目经验，按照他的话简历越投越迷茫，然后找到我们重新定制计划和资料，重新定制简历以下图片是整个辅助过程。

# 培训出来经过包装拿下四个offer，最高18k*15薪

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：18k*15薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

**情况说明：**刚培训结束，培训机构就业指导老师竟然让自己出去找项目，完全没有经验，什么都不会。

经过相关培训学过java，但是没有好项目来包装自己去找工作，经过我们的辅导，成功上岸！！

# 刚自学完，对面试非常惶恐，担心找不到工作？

• 工作年限：0-1年
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：未披露
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

​ 以下小伙伴是自学完，出来找工作，发现每次面试总是面试题回答的不满意，不是面试官想要的答案，还有项目经验是自学的完全拿不出手！

# 深信服26k*15薪，会问哪些技术？三年经验会有几轮面试

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：26k*15薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

说明：这个是最近找到的，我还专门做了一个面试总结采访，有兴趣的小伙伴可以看看。

# 坐标北京，30k*12薪

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：30k*12薪
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

说明：实际经验四年多，包装了一下写了五年多一些，这里hr面问什么也总结了

# 两个offer，上海11k&&湖南数字马力12k

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：11k；12k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。

# 三个offer，17k的银行外包，14.5k的阿里，中证18k，季度奖4-8k，每月休息九天

• 工作年限：未披露
• 学历：未披露
• 初始预期薪资：未披露
• 到手薪资：17k；14.5k；18k；8k
• 介绍：基于该案例公开描述整理，详细过程见下方内容。