1、业务表现服务不可用，转圈圈2、上日志Redisson + Netty 堆内存溢出（OOM）问题完整解决方案你遇到的核心错误是：Java 堆内存不足，且溢出发生在 Redisson 编码发送 Redis 命令 的阶段（Netty 编码器），这是典型的大对象 / 大批量命令 / 内存配置不足导致的 OOM。先给你最关键的结论：这个 OOM 不是普通的内存泄漏，90% 是因为你一次性往 Redis 发送了超大数据 / 批量命令，或者 JVM 堆内存配置太小，Redisson 编码时直接撑爆了堆。一、快速定位根因（3 个最常见原因）结合你的日志（CommandEncoder/CommandBatc...

本2硕9，力扣是没刷完的，八股是没背完的，准备先投中小厂练练手，逼自己先面试找找感觉。大厂到底什么时候才配投啊，看了面经能掰扯的最多才一半

想找暑假java后端实习 但是简历过不了 大佬们能帮忙看看嘛 谢谢！

1. 你之前接触过的中间件里，挑一个最熟的讲讲它的核心设计，重点说为什么要这样设计如果讲消息队列，比较容易拉开差距的不是背概念，而是把吞吐、可靠性、顺序性和扩展性之间的取舍讲清楚。比如一套高吞吐 MQ 通常会采用顺序写磁盘、分区模型、批量发送、批量拉取和零拷贝来提升吞吐，但这么设计以后，消费顺序只能在单分区内严格保证，跨分区顺序就必须交给业务自己兜底。再比如可靠性不是简单开个副本就完事了，生产端要考虑重试和幂等，Broker 要考虑刷盘和副本同步策略，消费端还要考虑重复消费和位点提交时机。真正难的是理解这些机制不是孤立存在的，而是围绕吞吐、延迟、可恢复性一起做平衡。2. 软件工程里的设计原则你...