校招 未知部门 / 后端开发 / 未知轮次

<h2>用友 全栈开发 高潜</h2> <p><em>来源为牛客付费专栏，以下仅收录公开可见内容，付费部分未收录。</em></p> <h2><span>1. 自我介绍</span></h2> <h2><span>2. MySQL 已开启半同步复制，用户提交修改后立即查询从库，为什么仍可能读到旧数据？</span></h2> <h2><span>3. React 页面中的防抖搜索为什么会同时出现旧状态读取和旧响应覆盖新结果？两类问题分别如何解决？</span></h2> <h2><span>4. 没想过考研吗?</span></h2> <h2><span>5. </span><code>ReentrantLock</code><span> 的条件等待为什么必须写在循环中？收到 </span><code>signal()</code><span> 后，线程为什么不能立即继续执行？</span></h2> <p><code>await()</code><span> 会将线程放入条件队列，释放锁，之后在满足唤醒条件时转移到锁的同步队列，重新竞争锁。</span><code>signal()</code><span> 只是让一个等待者具备重新竞争的资格，不会替调用者释放锁，也不保证等待者立即运行。等待者恢复时，目标条件可能已经被其他线程改变，还可能发生虚假唤醒，因此必须重新检查条件。条件判断、状态修改和通知应处于同一把锁的保护下；用 </span><code>if</code><span> 代替 </span><code>while</code><span>，容易让线程在资源已被抢走后继续执行非法操作。</span></p> <h2><span>6. 将 Snowflake 替换为 UUIDv7，能否同时解决数据库写入局部性、严格顺序和业务信息泄漏问题？</span></h2> <p><span>不能。UUIDv7 将毫秒级时间放在高位，通常比完全随机的 UUID 更有利于 B-tree 插入局部性，但同一毫秒内的排序取决于实现，并不天然满足跨节点严格递增。唯一性依赖随机位或相应生成策略，也不能直接当作业务发生顺序。时间字段还会暴露大致创建时间，不能承担访问控制职责。选型时应同时考虑 128 位索引带来的空间成本、生成器的回拨处理和数据库存储方式；若业务需要严格排序，应另设权威序列，而不是从标识符中推导。</span></p> <h2><span>7. React 并发渲染时，直接读取外部可变对象为什么可能产生界面撕裂？</span><code>useSyncExternalStore</code><span> 对快照有什么要求？</span></h2> <p><span>并发渲染可能在一次更新过程中暂停，而外部对象此时已经变化，导致不同组件读取到不同版本的数据。</span><code>useSyncExternalStore</code><span> 为外部状态提供订阅与快照读取协议，React 可以据此检查一致性。</span><code>getSnapshot</code><span> 在数据未变化时必须返回稳定结果，不能每次创建新对象；数据变化时又必须能反映新快照，不能原地修改对象后继续返回同一引用。服务端渲染还需要匹配的 </span><code>getServerSnapshot</code><span>，保证服务端输出与客户端 hydration 的初始视图一致。</span></p> <h2><span>8. Java 接口返回 </span><code>long</code><span> 类型主键，前端再原样提交，为什么可能操作到错误记录？JSON 序列化还能破坏哪些语义？</span></h2> <p><span>JavaScript 的 </span><code>Number</code><span> 无法精确表示所有 64 位整数，超过安全整数范围的值在解析阶段就可能丢失精度，之后转为字符串也无法恢复。主键应在接口契约中定义为十进制字符串，并贯穿查询参数、状态管理和缓存键。JSON 还不能原生表达对象引用关系、循环结构、</span><code>Map</code><span> 和 </span><code>Set</code><span>；日期通常变成字符串，</span><code>NaN</code><span> 会被序列化为 </span><code>null</code><span>，直接序列化 </span><code>BigInt</code><span> 会抛错。因此，序列化往返不是通用深拷贝，更不是无损的跨语言类型协议。</span></p> <h2><span>9. 两名审批人同时退出值班，数据库使用快照隔离，为什么仍可能违反“至少保留一人值班”的规则？</span></h2> <p><span>两个事务都可能从各自快照看到两人在岗，然后分别更新不同的记录。由于没有修改同一行，普通写写冲突检测可能允许两者提交，最终无人值班，这属于写偏差。解决方法是让不变量对应一个共同的并发控制点，例如先锁定值班组记录，再检查和更新成员状态；也可以使用真正提供所需保障的可串行化隔离，并处理事务中止重试。不能简单认为提高到某个名为“可重复读”的级别就一定安全，不同数据库的实现与保证并不相同。</span></p> <h2><span>10. 一个 BFF 请求需要聚合六个下游接口，为什么把所有调用并行化仍然可能放大尾延迟？</span></h2> <p><span>整体响应若必须等待全部结果，就取决于最慢分支；分支越多，碰到慢请求的概率越高。并行还可能争抢连接</span></p>