杭州某国企面经，超简单！！

近年来，"国企"已然成为程序员圈内备受青睐的职业选择，无论是应届生还是社会招聘，投身国企的热情都空前高涨。然而，僧多粥少的局面也使得进入国企的门槛逐年攀升，大部分求职者连面试机会都没有。

不过，接下来还是要对那些觉得去国企之后就很爽的同学泼一些冷水，避免脑子一热做出了不太好的决定。

1. 国企真的"稳定"吗？ 并非绝对。国企能提供的是"相对稳定"，但放眼未来五年、十年，甚至更长的时间维度，没有人能预见时代的变革。在宏观趋势面前，个体的职业轨迹充满了不确定性。
2. 国企就意味着"清闲"吗？ 这也未必。许多国企岗位的实际工作强度并不低，甚至可能伴随着重复性、流程化的工作内容，这对于追求技术创新与挑战的开发者而言，可能是另一种形式的消耗。

去国企之前，尽量还是要去网上搜索一下这家国企的一些信息。或者，更直接地就是找到这家国企的员工问问实际情况，如果可以的话。

另外，牛客上一位同学分享了四类需要谨慎选择的"国企"，总结的挺不错的，建议避雷一下！

之前星球里有一位球友放弃大厂 offer，去了某薪资只有大厂一半的国企，结果发现和自己想象的完全不一样，现在后悔死了。像这样的例子，还有很多。

说实话，国企的面试难度还是普遍非常简单的，关键是能够是否能够获取到面试机会和进入面试！

接下来，分享一篇杭州某国企 Java 后端的面经，大家感受一下，问的问题都挺简单基础的。

简单做个自我介绍

面试时的自我介绍，其实是你给面试官的"第一印象浓缩版"。它不需要面面俱到，但要精准、自信地展现你的核心价值和与岗位的匹配度。通常控制在 1-2 分钟内比较合适。一个好的自我介绍应该包含这几点要素：

1. 用简单的话说清楚自己主要的技术栈于擅长的领域，例如 Java 后端开发、分布式系统开发；
2. 把重点放在自己的优势上，重点突出自己的能力，最好能用一个简短的例子支撑，例如：我比较擅长定位和解决复杂问题。在[某项目/实习]中，我曾通过[简述方法，如日志分析、源码追踪、压力测试]成功解决了[某个具体问题，如一个棘手的性能瓶颈/一个偶现的 Bug]，将[某个指标]提升了[百分比/具体数值]。
3. 简要提及 1-2 个最能体现你能力和与岗位要求匹配的项目经历、实习经历或竞赛成绩。不需要展开细节，目的是引出面试官后续的提问。
4. 如果时间允许，可以非常简短地表达对所申请岗位的兴趣和对公司的向往，表明你是有备而来。

把你的项目给我简单介绍一下

作为求职者，我们可以从哪些方案去准备项目经历的回答：

1. 梳理项目全貌 ：
   • 一句话概括项目：用简洁的语言说清楚这个项目是做什么的（核心业务/目标）以及为什么要做（项目背景、要解决什么痛点）。
   • 核心功能与亮点：介绍项目的主要功能模块，特别是那些技术含量高或业务价值大的部分。
   • 技术架构与选型：能清晰地说明项目的整体技术架构（比如是微服务、单体？用了哪些中间件？），并解释为什么选择这些技术（技术选型的考量）。准备好可能被要求画简要架构图或解释关键模块设计。
2. 明确你的角色与贡献 ：
   • 你的角色：清楚说明你在项目中担任的角色（比如核心开发者、模块负责人、项目经理等）。
   • 具体职责：你具体负责了哪些模块或任务？
   • 关键贡献（重中之重！）：用 STAR 法则 (Situation, Task, Action, Result) 来准备几个实际案例。重点突出你通过具体行动取得了可量化的成果或解决了关键问题，一定要具体场景，而非罗列技术。例如，"负责优化 XX 接口，通过 A、B、C 措施，将响应时间从 X 降低到 Y，提升了 Z% 的用户体验"。
3. 准备解决问题的亮点案例 ：
   • 挖掘挑战：回忆项目中遇到的最棘手的技术难题、性能瓶颈、或者复杂的业务逻辑实现。这个在面试中很可能会问到，例如面试官会问你："面试中遇到了什么困难？如何解决的？"。
   • 展现思路：详细说明你是如何分析问题（用了什么工具？怎么定位的？）、思考解决方案（考虑了哪些方案？为什么选择最终方案？）、最终如何解决的，以及结果如何。
   • 提炼收获：从解决这个问题的过程中，你学到了什么？技术上有什么成长？或者对业务有了更深的理解？
4. 深入理解关键技术：吃透你在这个项目中用到的技术（举个例子，你的项目经历使用了 Seata 来做分布式事务，那 Seata 相关的问题你要提前准备一下吧，比如说 Seata 支持哪些配置中心、Seata 的事务分组是怎么做的、Seata 支持哪些事务模式，怎么选择？）。

你的数据是存在哪里的？用过国产数据库吗？

我主要使用 MySQL 作为关系型数据库来持久化核心的业务数据，比如用户信息、订单详情、产品信息等。选择 MySQL 是因为它成熟稳定、社区支持好、有大量的最佳实践，并且能够满足我们大部分场景下的事务一致性和数据可靠性要求。

为了提升系统的响应速度和并发能力，特别是针对热点数据（例如热门博客、频繁访问的配置信息）的快速访问，我们引入了 Redis 作为分布式缓存。这不仅能显著加快查询速度，还能有效减轻 MySQL 的压力，避免在高并发情况下数据库成为瓶颈。

在我过往的实际项目经验中，还没有直接使用过国产数据库。我平时接触和学习的，以及在项目中实际选型和应用的，主要还是像 MySQL、PostgreSQL、Redis、MongoDB 这些在业界广泛应用且生态成熟的开源或商业数据库产品。不过，我对国产数据库的发展一直保持关注，也乐于去学习和尝试使用国产数据库。

MySQL 数据库面试题汇总可参考笔者写的这篇文章：MySQL 常见面试题总结（MySQL 基础、存储引擎、事务、索引、锁、性能优化等）

缓存过期策略了解吗？

常用的过期数据的删除策略就下面这几种：

1. 惰性删除：只会在取出/查询 key 的时候才对数据进行过期检查。这种方式对 CPU 最友好，但是可能会造成太多过期 key 没有被删除。
2. 定期删除：周期性地随机从设置了过期时间的 key 中抽查一批，然后逐个检查这些 key 是否过期，过期就删除 key。相比于惰性删除，定期删除对内存更友好，对 CPU 不太友好。
3. 延迟队列：把设置过期时间的 key 放到一个延迟队列里，到期之后就删除 key。这种方式可以保证每个过期 key 都能被删除，但维护延迟队列太麻烦，队列本身也要占用资源。
4. 定时删除：每个设置了过期时间的 key 都会在设置的时间到达时立即被删除。这种方法可以确保内存中不会有过期的键，但是它对 CPU 的压力最大，因为它需要为每个键都设置一个定时器。

Redis 采用的是那种删除策略呢？

Redis 采用的是 定期删除+惰性/懒汉式删除 结合的策略，这也是大部分缓存框架的选择。定期删除对内存更加友好，惰性删除对 CPU 更加友好。两者各有千秋，结合起来使用既能兼顾 CPU 友好，又能兼顾内存友好。

另外，Redis 提供了 6 种内存淘汰策略：

1. volatile-lru（least recently used） ：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
2. volatile-ttl ：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。
3. volatile-random ：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
4. allkeys-lru（least recently used） ：从数据集（server.db[i].dict）中移除最近最少使用的数据淘汰。
5. allkeys-random ：从数据集（server.db[i].dict）中任意选择数据淘汰。
6. no-eviction（默认内存淘汰策略）：禁止驱逐数据，当内存不足以容纳新写入数据时，新写入操作会报错。

4.0 版本后增加以下两种：

1. volatile-lfu（least frequently used） ：从已设置过期时间的数据集（server.db[i].expires）中挑选最不经常使用的数据淘汰。
2. allkeys-lfu（least frequently used） ：从数据集（server.db[i].dict）中移除最不经常使用的数据淘汰。

详细介绍可以查看我写的这篇文章（强烈推荐，写的非常详细）：为什么 Redis 不立刻删除已经过期的数据？。

Redis 缓存面试题汇总可参考笔者写的这几篇文章：

• Redis 常见面试题总结（上）（Redis 基础、应用、数据类型、持久化机制、线程模型等）
• Redis 常见面试题总结(下)（Redis 事务、性能优化、生产问题、集群、使用规范等）

用过哪些设计模式？

在我做过的项目中，我使用过多种设计模式来提高代码的可维护性、可扩展性和复用性。其中比较常用的有：

• 单例模式 (Singleton Pattern): 确保一个类在整个应用中只有一个实例，并提供一个全局统一的访问点。比如在管理系统全局配置对象、数据库连接池、或者一些需要集中控制的工具类实例时，我会采用单例模式。这样做的好处是避免了不必要的对象创建开销，也保证了对共享资源的统一访问和管理。
• 工厂模式 (Factory Pattern): 包括简单工厂、工厂方法和抽象工厂。将对象的创建过程封装起来，使得客户端代码与具体对象的创建解耦。当系统中需要根据不同的条件或类型创建不同的对象实例时，工厂模式非常有用。
• 策略模式 (Strategy Pattern): 定义了一系列算法，并将每个算法封装起来，使它们可以相互替换。当一个功能有多种实现方式，且需要在运行时动态选择其中一种时，我会使用策略模式。例如，文件上传到不同的云存储（阿里云 OSS、腾讯云 COS）可以用策略模式来封装各自的上传逻辑。
• 观察者模式 (Observer Pattern): 定义了对象之间的一对多依赖关系，当一个对象（被观察者）的状态发生改变时，所有依赖于它的对象（观察者）都会得到通知并自动更新。这在实现事件驱动或消息通知系统时非常有用，例如，当用户下单成功后，需要同时通知库存系统、日志系统和邮件系统。
• 模板方法模式： 在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中实现。当多个类有相似的处理流程，但某些特定步骤的实现不同时，可以使用模板方法。比如，在处理不同类型文件导入的通用流程中（读取文件 -> 解析数据 -> 数据校验 -> 数据入库），解析数据和数据校验的具体逻辑可能因文件类型（CSV, Excel）而异，这时就可以用模板方法模式。

什么时候需要用到单例模式？

当希望在整个应用程序生命周期中，某个类有且仅有一个实例，并需要为该实例提供一个全局访问点时，就应该考虑使用单例模式。

主要应用场景包括：

1. 需要频繁创建和销毁的重量级对象： 对于创建成本很高的对象（如数据库连接池、线程池），使用单例模式可以避免重复创建和销毁带来的性能开销，实现资源复用。
2. 需要共享资源的全局状态管理： 当多个模块需要访问同一个共享资源或配置信息时，例如网站的访客计数器、应用程序的全局配置文件读取器，使用单例可以保证数据的一致性。
3. 工具类实例： 对于无状态的工具类，例如日志记录器 (Logger)、ID 生成器等，创建一个单一实例供全局使用即可，无需在各处重复实例化。

总结： 使用单例模式的核心目的是控制实例数量 和提供全局访问，从而达到节约系统资源、保证数据一致性的目的。

更多设计模式面试题可参考：设计模式常见面试题总结（PDF 形式，汇总了常见设计模式的面试问题）

如何理解线程安全和不安全？

线程安全和不安全是在多线程环境下对于同一份数据的访问是否能够保证其正确性和一致性的描述。

• 线程安全指的是在多线程环境下，对于同一份数据，不管有多少个线程同时访问，都能保证这份数据的正确性和一致性。
• 线程不安全则表示在多线程环境下，对于同一份数据，多个线程同时访问时可能会导致数据混乱、错误或者丢失。

Java 并发面试题汇总可参考笔者写的这几篇文章：

• Java 并发常见面试题总结（上）（多线程基础知识，例如线程和进程的概念、死锁）
• Java 并发常见面试题总结（中）（各种锁，例如乐观锁和悲观锁、synchronized关键字、ReentrantLock）
• Java 并发常见面试题总结（下）(ThreadLocal、线程池、Future、AQS、虚拟线程等)

一行命令如何杀死所有 Java 进程

在 Linux 或 macOS 系统中：

ps -ef | grep '[j]ava' | awk '{print $2}' | xargs kill -9

• ps -ef: 列出当前系统所有正在运行的进程的详细信息。
• grep '[j]ava': 筛选出那些命令行中包含 "java" 字符串的进程。
• awk '{print $2}': 从筛选后的结果中，提取第二列，也就是进程的 PID (Process ID)。
• xargs kill -9: 将前面提取到的所有 PID 作为参数，传递给 kill -9 命令。kill -9 会发送 SIGKILL 信号，强制终止这些进程。

一个更简洁的方案是：

pkill -9 -f java

在 Windows 系统中：

taskkill /F /IM java.exe /T

• taskkill: Windows 中用于终止进程的命令。
• /F: 表示强制终止进程。
• /IM java.exe: 指定要终止的进程的映像名称（Image Name），这里是所有名为 java.exe 的进程。
• /T: （可选但推荐）终止指定的进程以及由它启动的任何子进程。