校招2000人，可以把至少300户的大村的人都招了，不愧是美团。

大家好，我是皇子。

好好的校招为什么说到一个村了呢？

因为前段时间，听老家里的亲戚说：现在生意不好做，村里之前有点钱就各种酒吧耶耶耶挥霍的年轻人，很多人都开始黄袍加身送外卖去了。

黄袍加身没啥不好的，可能我们技术人哪一天变老了（35岁的老），那也得打满鸡血干起来。

工作没有贵贱，我们尊重每一份坚守岗位，靠着自己的体力、脑力、精神力去赚那碎银几两的每一个人。不过对于那些有点钱就各种挥霍的人，我是觉得无法持久的。

那么对于美团这个企业，在校招中能提供的岗位就很丰富了：

面向毕业时间在2024年11月至2025年10月的海内外院校应届毕业生，预计招募6000人。

覆盖技术，产品，商业分析，运营，金融，供应链，职能，市场营销，设计，销售、客服与支持等10大类职位、100余种岗位，遍布全国及海外数十个城市。

关于薪资方面，我搜集了网上资料，发现美团在2024届互联网校招的薪资水平相较于过去有了显著提升，已经摆脱了开水团的旧称

网上资料整理，仅供参考

白菜价：21k，除去各种福利补贴之外的总包大概就是21k ×15.5=32w；
sp offer：24k-26k，除去各种福利补贴之外的总包大概就是 24k/26k×15.5=37w~40w；
ssp offer：27k/28k/29k，除去各种福利补贴之外的总包大概就是27k/28k/29k×15.5=42w~48w；

既然美团秋招准备开始了，为了让大家能黄袍加身，这里也列觉几道关于美团校招Java后端面经的一面题型。

更多的技术知识可以访问皇子哥的网站：https://itgogogo.cn 免费阅读。

你知道的最新JDK版本有哪些特性？

最新版本的 JDK 截至2024年8月是 JDK 22，对应的最新版本的特性

1、性能优化：更高效的执行与更低的资源消耗。

通过引入更先进的即时编译器技术（JIT），JDK团队进一步提升了Java程序的执行效率。这些优化包括对热点代码的更精准识别、更高效的代码生成策略以及更智能的内存管理算法。

此外，JVM（Java Virtual Machine）的内存模型也得到了改进，减少了垃圾收集（GC）的停顿时间，使得Java应用在处理大规模数据时能够更加流畅和高效。

2、新API与语言特性：更丰富的编程体验。

模式匹配（Pattern Matching）：Java 17 引入的预览特性之一，在新版中可能得到进一步完善。模式匹配允许开发者以更加直观和简洁的方式处理类型匹配和条件逻辑，减少了样板代码和提高了代码的可读性。

文本块（Text Blocks）：这一特性使得在Java中编写多行字符串变得更加简单和直观。开发者无需再使用复杂的字符串拼接或转义字符，而是可以直接在代码中嵌入多行文本。

新的日期和时间API：随着时间的推移，原有的日期和时间API（如java.util.Date和java.util.Calendar）已经显得过时且难以使用。新版JDK可能会继续扩展和完善新的日期和时间API（如java.time包），提供更加强大和灵活的日期时间处理能力。

3、安全性与兼容性提升

新版JDK在安全性方面进行了多项改进，包括增强了对加密算法的支持、提高了JVM的安全防护能力以及引入了更多的安全检测机制。

同时，JDK团队还致力于提升JDK的兼容性，确保旧有代码能够在新版JDK上平稳运行，减少迁移成本和风险。

Spring Cloud 的核心组件有哪些？

服务发现——Netflix Eureka

客户端负载均衡——Netflix Ribbon

断路器——Netflix Hystrix

服务网关——Netflix Zuul

分布式配置——Spring Cloud Config

说出ArrayList,LinkedList的存储性能和特性

ArrayList,使用数组方式存储数据，查询时，ArrayList是基于索引(index)的数据结构，可以直接映射到，速度较快；但是插入数据需要移动数据，效率就比LinkedList慢一点~

LinkedList,使用双向链表实现存储,按索引数据需要进行前向或后向遍历，查询相对ArrayList慢一点；但是插入数据速度较快。

LinkedList比ArrayList开销更大，因为LinkedList的节点除了存储数据，还需要存储引用。

MySQL的乐观锁和悲观锁了解吗？

乐观锁与悲观锁：乐观锁与悲观锁都属于是一种思想，而非实际的 mysql 锁机制。

悲观锁：只要使用了锁机制都属于悲观锁

乐观锁：不使用锁机制

悲观锁（Pessimistic Concurrency Control）

悲观锁认为被它保护的数据是极其不安全的，每时每刻都有可能被改动，一个事务拿到悲观锁后，其他任何事务都不能对该数据进行修改，只能等待锁被释放才可以执行。

数据库中的行锁，表锁，读锁，写锁均为悲观锁。

乐观锁（Optimistic Concurrency Control）

乐观锁认为数据的变动不会太频繁。

乐观锁通常是通过在表中增加一个版本(version)或时间戳(timestamp)来实现，其中，版本最为常用。

设计缓存时你会考虑什么问题

问题很开放，你可以回答考虑缓存穿透、缓存雪崩、缓存击穿的问题，这里只是抛砖引玉，你还可以回答缓存键值设计、缓存性能优化等。

缓存穿透问题

先来看一个常见的缓存使用方式：读请求来了，先查下缓存，缓存有值命中，就直接返回；缓存没命中，就去查数据库，然后把数据库的值更新到缓存，再返回。

缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，进而给数据库带来压力。通俗点说，读请求访问时，缓存和数据库都没有某个值，这样就会导致每次对这个值的查询请求都会穿透到数据库，这就是缓存穿透。

缓存穿透一般都是这几种情况产生的：

业务不合理的设计，比如大多数用户都没开守护，但是你的每个请求都去缓存，查询某个userid查询有没有守护。

业务/运维/开发失误的操作，比如缓存和数据库的数据都被误删除了。

黑客非法请求攻击，比如黑客故意捏造大量非法请求，以读取不存在的业务数据。

如何避免缓存穿透呢？一般有三种方法

如果是非法请求，我们在API入口，对参数进行校验，过滤非法值。

如果查询数据库为空，我们可以给缓存设置个空值，或者默认值。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）。

使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。

缓存雪奔问题

缓存雪奔：指缓存中数据大批量到过期时间，而查询数据量巨大，请求都直接访问数据库，引起数据库压力过大甚至down机。

产生的原因：缓存雪奔一般是由于大量数据同时过期造成的

解决：

可通过均匀设置过期时间解决，即让过期时间相对离散一点。如采用一个较大固定值+一个较小的随机值，5小时+0到1800秒酱紫。

Redis 故障宕机也可能引起缓存雪奔。这就需要构造Redis高可用集群啦。

缓存击穿问题

缓存击穿：指热点key在某个时间点过期的时候，而恰好在这个时间点对这个Key有大量的并发请求过来，从而大量的请求打到db。

缓存击穿与缓存雪崩看着有些像但其实是有区别的，缓存雪奔是指数据库收到大量的请求，造成压力过大甚至down机；缓存击穿只是大量并发请求到了DB数据库层面。可以认为击穿是缓存雪奔的一个子集吧。有些文章认为它俩区别，是区别在于击穿针对某一热点key缓存，雪奔则是很多key。

解决方案就有两种：

使用互斥锁方案。缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。

“永不过期”，是指没有设置过期时间，或者是热点数据快要过期时，通过定时任务去更新和设置过期时间。