1. 笔试复盘概览这套题到底在考什么拿到“用友2017秋招笔试题三”这个题目的时候很多人的第一反应是找原题、对答案但我建议大家先停下来想一个问题一套校招笔试题它真正想筛选的到底是什么用友是国内老牌的企业服务厂商主打ERP、云服务、人力资源、财务软件这些To B方向的产品。秋招笔试题三这套卷子从当时的面貌来看主要面向Java开发、后端开发、测试开发这些技术岗位。它不像互联网大厂那样偏爱考“手撕红黑树”或“设计一个秒杀系统”而是更偏重基础扎实度、工程习惯、数据库设计能力以及你对企业级应用开发的理解。这一点和用友的业务属性是强相关的。做企业软件的公司最怕的不是候选人不会某个偏门算法而是写出来的代码在生产环境里跑不稳、数据算不对、多人在线时拖垮服务。所以笔试题的考察重心会明显偏向Java核心基础、集合类原理、SQL与数据库设计、多线程与并发、JVM基础外加一两道算法题来摸底逻辑思维。这篇文章我就以这套笔试题目为线索结合我自己当年复习和后来面试别人时看到的情况把每类题目的考察目的、难点、答题思路以及我踩过的坑和后来总结出来的教训一次性聊透。无论你是正在准备校招、社招换坑还是已经在写业务代码想补一补基础这篇内容应该都比单纯搜一份“笔试题答案”更有价值。2. 题型构成与考察方向拆解2.1 选择题范围广但深度有限拼的是平时积累用友这套笔试题的选择题部分覆盖了Java基础语法、面向对象、异常处理、集合类、IO流、多线程基础、数据库SQL、计算机网络常识等。单题难度不算大但胜在范围宽很容易考出“你到底是真学过还是背过面试题”的区别。举个例子这类题目里很常见的考点是String、StringBuilder、StringBuffer的区别。看着简单但真正能答清楚的人并不多。很多人只会说“String不可变StringBuilder效率高”但问到为什么不可变、StringBuffer和StringBuilder到底差在哪里、字符串常量池的作用范围就卡壳了。这种题就是典型的“基础不牢地动山摇”型考点。还有一些网络基础题比如TCP三次握手、四次挥手的状态变化HTTP的几种请求方法区别这些在选择题里出现频率很高。对做后端开发的人来说这些是逃不掉的底层知识哪怕你平时写代码很少直接碰Socket但理解这些机制对你排查线上问题、设计接口、处理超时重试都很有帮助。我当时复习选择题的策略很简单把Java基础、集合、JVM、并发、MySQL、网络这几块核心知识做成思维导图每个知识点都要能讲出“是什么、为什么、怎么用、有什么坑”而不是只看结论。用这种方法过一遍选择题基本不会成为失分点。2.2 简答题考察“能不能把话说明白”简答题部分用友那几年常考的有这么几类类的加载机制、JVM内存模型、HashMap的底层实现原理、线程池的核心参数和执行流程、事务的ACID特性和隔离级别、索引的底层数据结构等。这类题目的评分标准和很多人想象的不一样——不是看你有没有背到标准答案而是看你能不能把逻辑链条讲完整。比如问HashMap底层实现只回答“数组加链表”只能拿一半分。完整的回答路径应该包含为什么用数组O(1)查找、为什么会出现哈希碰撞、链表和红黑树分别解决什么场景的问题、什么时候转化链表长度达到8且数组长度达到64、扩容机制resize的触发条件和数据迁移方式、为什么JDK 1.8要把头插法改为尾插法循环链表问题。我在复习简答题的时候特别推荐一个方法用费曼学习法把自己当成面试官用嘴把每个知识点完整讲出来讲到能说服自己为止。这个方法看起来有点傻但非常有效。因为很多知识点你眼睛看着会嘴上一讲就发现逻辑是断的这就是真正的薄弱点。2.3 编程题手写代码的熟练度和思路展示编程题部分用友这套题出现过的类型大致有单例模式手写懒汉、饿汉、双重检查锁、静态内部类、排序算法快排、冒泡、归并、链表反转、二叉树遍历、字符串处理类题目、以及一些简单的动态规划。不要小看这些看似“基础”的题目。手写单例模式看起来简单但能一次写对双重检查锁的人比例并不高。volatile关键字加不加、为什么加、synchronized加在方法上还是代码块上、锁的细粒度怎么控制这些都是实打实的考察点。我对编程题的建议就一条不要只会在IDE里写要能在一张白纸上或者一个空白编辑器里把代码完整写出来并且能自己解释每一行代码的作用。练到这种程度考试的时候才不会因为紧张而手抖漏掉关键代码。3. 几道高频核心题的精讲3.1 经典考点HashMap的底层实现与并发问题HashMap在Java笔试题里的出现频率可以说仅次于“自我介绍”和“你有什么缺点”。用友这道题从2017年考到现在核心逻辑一直没有变。首先要明确JDK 1.8及以后的HashMap底层是“数组 链表 红黑树”的结构。数组的每个位置是一个桶bucket通过key的hash值经过扰动函数处理后用(n - 1) hash计算存储位置。为什么要用(n - 1) hash而不是hash % n因为当n是2的幂次方时位运算(n-1) hash和取模hash % n的结果是一样的但位运算的性能更高。这里就是考察“能否从性能角度理解设计细节”的点。链表什么时候转红黑树两个条件同时满足链表长度达到8且数组长度达到64。为什么是8这是基于泊松分布的数学计算在负载因子0.75的情况下链表长度达到8的概率已经低到千万分之一级别。引入红黑树的目的是应对极端哈希冲突场景避免查询退化为O(n)。并发问题JDK 1.7的HashMap在多线程扩容时头插法可能导致环形链表get操作时会死循环。JDK 1.8改为尾插法从数据层面修复了这个问题但HashMap本身仍然不是线程安全的多线程写入仍然可能丢失数据。如果面试官问“有什么线程安全的替代方案”标准回答路径是Hashtable全表锁并发低、Collections.synchronizedMap包装类也是全表锁、ConcurrentHashMap分段锁/CAS局部锁并发能力强。3.2 线程池参数你真的理解corePoolSize吗ThreadPoolExecutor是Java并发包里的核心类也是用友这类企业级开发笔试的高频考点。这个类有七个构造参数但真正能讲透的人不多。核心参数有corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime非核心线程空闲存活时间、unit时间单位、workQueue任务队列、threadFactory线程工厂、handler拒绝策略。这里有一个比较深入的问题当一个任务提交给线程池时执行顺序是什么很多人会背“先核心线程、再队列、再非核心线程、最后拒绝策略”但对“队列什么时候开始接收任务”理解不到位。准确的流程是当前线程数小于corePoolSize时新建线程执行任务线程数达到corePoolSize后任务进入workQueue排队队列满且线程数小于maximumPoolSize时创建非核心线程执行任务队列满且线程数已经达到maximumPoolSize时触发拒绝策略。关键点在于核心线程被占用后不是立刻创建新线程而是先把任务塞队列。只有队列也满了才拉满线程数。这个设计和很多人直觉不一样但非常重要。拒绝策略有四种AbortPolicy直接抛异常、CallerRunsPolicy调用者线程执行任务、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃最老的任务。实际开发中CallerRunsPolicy比较常用因为这种策略下任务不会被丢弃但会拖慢提交线程的速度起到一种自然限流的效果。补充一个工作中常遇到的情况线程池参数设置不合理导致线上服务频繁Full GC或者任务堆积。我见过很多团队把corePoolSize设置得很大比如20、50但实际机器配置跟不上结果线程切换开销惊人系统吞吐量反而下降。合理的做法是根据CPU核心数、任务类型CPU密集还是IO密集、峰值QPS来估算。CPU密集任务通常设置CPU核心数 1IO密集任务可以提高到CPU核心数 * 2甚至更高结合压测结果调优。3.3 SQL优化实战为什么你的SQL越写越慢用友做企业软件出身数据库设计几乎是笔试必考项。常见题目类型包括根据业务场景写SQL、给一个慢查询说优化思路、设计某业务模块的表结构。有一道典型的题目是这样的一张用户订单表数据量过了千万现在要查询某用户在最近30天内的订单记录SQL很慢怎么优化看到这种题先别急着说“加索引”。完整的思路应该是先看执行计划确认慢在哪里全表扫描、临时表、文件排序等确认索引情况user_id和order_time是否有联合索引最优方案是创建(user_id, order_time)的联合索引注意字段顺序是等值查询在前、范围查询在后避免在索引列上使用函数或隐式类型转换考虑分页查询的深翻页问题用游标方式代替大偏移量limit如果表数据量实在太大考虑按时间分表或归档历史数据。这里有一个细节非常值得展开联合索引的最左前缀原则。如果查询条件是where user_id ? and order_time between ? and ?创建(user_id, order_time)联合索引后MySQL会先按user_id精确定位再在命中的范围内按order_time走索引排序效率非常高。但如果你把索引建成了(order_time, user_id)那这条查询就完全用不上索引了因为最左前缀列是order_time在order_time不等值的情况下user_id的过滤条件无法走索引。这是很多人的认知盲区也是SQL优化题的高频埋坑点。对应到实战场景做报表查询或者后台管理系统的列表页时这种慢SQL几乎是必踩的坑。我的经验是每个列表查询都应该根据实际的筛选条件组合预先设计好对应的索引而不是等线上告警了再临时补。4. 实操环节用一份“模拟答题卷”还原考试现场4.1 从读题到落笔编程题的答题节奏控制我见过很多同学在笔试的编程题环节折戟不是不会做而是时间分配崩了。用友这套题编程题一般是两道一道偏数据结构一道偏实际应用建议时间控制在25分钟以内留出时间检查前面的选择题和简答题。拿到一道编程题正确的读题顺序是第一步明确输入范围和约束条件第二步确认输出格式第三步在纸上写测试用例第四步确定算法的时间和空间复杂度第五步才动手写代码。举个例子如果题目是“实现一个函数将字符串中的每个单词反转但是单词之间的相对顺序不变”很多人上来就写结果漏掉了“String是不可变的每次拼接会创建新对象”这个点。用StringBuilder或者直接把字符串拆成char数组原地操作才是面试官期望看到的解法。写代码的时候我习惯先写出关键方法的签名和主干逻辑再补细节。比如写快排先把partition函数想清楚再考虑递归终止条件这样框架不乱不会写到一半卡住。另外一个很现实的建议先保证能跑通再去优化性能。在笔试平台上编译通过并且样例通过至少能拿到一半以上的分而一个完美的思路但编译不通过的答案往往是零分。4.2 简答题的“三段式”答题法简答题想要拿高分我总结了一个三段式结构先下定义再讲原理/流程最后说应用场景或注意事项。拿“请简述JVM内存模型”这道题来说低分答案是直接把各类内存区域的名字罗列一遍堆、栈、方法区、程序计数器、本地方法栈然后解释一句“堆存对象栈存引用”。这种答案太单薄。高分答案的思路应该是首先说明JVM内存模型是“线程共享”和“线程私有”两大块线程共享部分包括堆和方法区JDK 1.8之后方法区被元空间取代堆是对象实例分配的主要区域元空间使用本地内存不受堆大小限制线程私有部分包括虚拟机栈、本地方法栈、程序计数器。虚拟机栈里的栈帧对应一次方法调用包含局部变量表、操作数栈、动态链接、方法出口最后补充一条实际应用栈溢出StackOverflowError和堆溢出OutOfMemoryError的触发条件以及调优时如何通过-Xmx、-Xms参数控制堆大小通过-Xss控制栈大小。这样的回答逻辑链条完整深度也有面试官一眼就能看出你是真的理解而不是背了答案。4.3 数据库设计题的踩坑点第一范式到第三范式不是背出来的有一类题目是“设计一个简单的员工-部门-薪资记录表结构”看起来简单但里面埋了很多坑。比如员工和部门的关系是一对多还是多对多一个员工是否可能同时在多个部门任职在ERP系统里这种兼职场景很常见薪资记录要不要保留历史版本还是只保留当前值在实际的表结构设计中很多人犯的错是为了“简化”而丢失了关键的业务约束。比如薪资字段直接用DECIMAL(10,2)存储但没有考虑历史追溯的需求。在企业软件里薪资调整记录、部门调动记录都是必须保留审计轨迹的如果一开始设计时就忽略了后面返工的代价极大。笔试答题的时候最好把设计思路分为几步来展示画出核心实体和关系可以用文字描述关联关系列出每个表的字段、类型、是否允许为空说明主外键设计、唯一约束、索引策略补充一条站在业务角度上哪些字段需要加冗余来提升查询性能哪些字段必须拆表保证数据一致性。这个过程不仅是在答题也在展示你对企业级软件设计的理解。而这恰恰是用友这类公司特别看重的。5. 避坑指南那些年我踩过的笔试大坑5.1 编译器开挂一时爽笔试题上一脸懵很多同学平时写代码太依赖IDE的自动补全、快捷键、语法提示到了笔试环境尤其是不带IDE的在线编辑器就感觉双手被绑住。有一个挺典型的例子写一个线程安全的单例IDE里new对象、synchronized、volatile都是自动补全的谁都会。但到了笔试平台要自己一行一行敲出来很多人就会漏掉最关键的一步——双重检查锁为什么要加volatile。不加volatile由于指令重排序某线程可能拿到一个“未完全初始化”的对象这在并发场景下是致命bug。这里解释一下原理instance new Singleton()这行代码在JVM层面不是原子操作它分成三步——分配内存、初始化对象、将引用指向内存。如果不加volatile第二步和第三步可能被重排序导致一个线程读到引用非null但对象还未完成初始化的内存拿到一个半成品对象。这个知识点我强烈建议每个准备笔试的人都要亲手写一遍并且能清晰地讲出原因。因为它在简答题、编程题、面试聊方案三个环节都可能出现。5.2 集合类的“线程安全”误区只要问到集合类十个候选人里五六个都会说“Vector是线程安全的”然后就没有然后了。这句话不能说错但远不够。你会追问自己吗Vector为什么线程安全因为它的每个方法都用synchronized修饰但这也意味着粒度过大并发性能很差所以现在实际上很少使用了。更值得了解的是Collections.synchronizedList、CopyOnWriteArrayList、ConcurrentHashMap各自的适用场景。CopyOnWriteArrayList适用于读多写极少的场景。它每次修改都是复制整个底层数组写操作代价很高但改的时候读线程不需要加锁所以读性能极高。如果你在面试中说“我在一个缓存场景里用CopyOnWriteArrayList存配置信息因为配置更新非常少但读取非常频繁”这就是一个加分回答因为体现出了根据场景选型的能力。5.3 复习资料贵精不贵多我给一个非常真心的建议不要收集几十个G的笔试资料然后每个都看两眼就扔。笔试复习最好的方式是“做真题 精读一本基础书 反复画逻辑图”。我当时复习的时候只用了Java核心技术卷一、MySQL技术内幕、以及网上能找到的历年校招真题配合自己整理的笔记效果比刷一大堆教程好得多。每次做完一套真题把错题按“知识点”归档然后逐个击破。比如发现HashMap的底层原理答不全就花一天时间把这个知识点彻底搞透再看看相关的二叉树、HashTable、ConcurrentHashMap形成知识网络而不是孤立地背答案。6. 常见问题与排查技巧实录问题我当时犯的错正确的处理方式选择题里Java集合和HashMap的题错了只记得“数组链表”没有掌握红黑树转换条件和扩容细节把源码级别的实现逻辑完整走一遍用画图方式理解数据结构变化简答题JVM内存模型答得太单薄只罗列内存区域名没有说明各区域作用、异常场景、调参方法按“是什么-原理-实际应用”三段式组织答案配合画内存布局图手写线程池参数时漏掉了两种常见拒绝策略只知道抛异常和丢弃不会讲CallerRunsPolicy和DiscardOldestPolicy每个策略结合一个实际调度场景理解比如调用者执行策略适合限流数据库慢SQL优化题答不到点子上直接说“加索引”没有分析索引结构和查询条件匹配先看执行计划、分析查询条件、设计联合索引、再考虑分表和归档编程题没控制好时间第一题磨蹭太久第二题没时间写先扫一遍所有题的难度先易后难编程题超过25分钟就先放下上面这个问题表相信很多人看着眼熟。这些坑不是“只有不够细心才会踩”而是没有掌握正确的知识组织方式导致的全盘崩溃。准备笔试的过程本质上是把零散知识点串成能力体系的过程。如果时间紧张我的建议是优先把这几个方向学透Java集合类尤其是HashMap和ConcurrentHashMap、JVM内存与垃圾回收、线程池和常用并发工具类、MySQL索引与事务隔离级别、Spring的IOC和AOP原理。这五个方向基本上覆盖了用友这类企业级公司笔试题的八成以上考点。7. 笔试之后这套题对实际工作的影响很多人觉得笔试题考完就完了和实际工作关系不大但我个人体会正好相反。用友这套题里涉及的很多知识点在我后来做企业级项目开发时反复被用到。单例模式看起来是个八股文考点但你在写配置管理工具、连接池对象、Spring Bean默认作用域的时候天天和单例打交道。理解它的线程安全性能帮你避免很多线上的“灵异问题”——比如多环境下配置读取不一致、共享状态被并发修改等。SQL优化题也不是纸上谈兵。一个实际的企业应用数据量一旦过了千万级SQL写得好不好性能差距是几十倍的。我在项目里见过一条查询因为没走索引导致数据库CPU飙升、接口响应从20ms退化到3s的线上事故。当时排查的时候第一个动作就是看执行计划和笔试题目里的思路完全一致。线程池更不用说了。企业应用的后端服务几乎都是用线程池处理HTTP请求的。什么时候调核心线程数、要不要用有界队列、拒绝策略选哪个这些决策直接影响系统的稳定性。所以别把笔试当成一场应试它是一个很好的“能力体检”。通过一套好题目你可以清楚看到自己哪些基础牢固、哪些只是看似牢固。用这种心态去准备和复盘收获会大很多。最后再分享一个我自己体会特别深的小技巧每次做完一套真题不要急着对完答案就扔花半小时在纸上画一张“这套题考了哪些知识点”的思维导图标出自己拿不准的地方然后针对性地补。这个方法坚持一个招聘季你的知识体系会比以前扎实非常多。祝看到这里的同学都能拿到心仪的offer。
1. 笔试复盘概览这套题到底在考什么拿到“用友2017秋招笔试题三”这个题目的时候很多人的第一反应是找原题、对答案但我建议大家先停下来想一个问题一套校招笔试题它真正想筛选的到底是什么用友是国内老牌的企业服务厂商主打ERP、云服务、人力资源、财务软件这些To B方向的产品。秋招笔试题三这套卷子从当时的面貌来看主要面向Java开发、后端开发、测试开发这些技术岗位。它不像互联网大厂那样偏爱考“手撕红黑树”或“设计一个秒杀系统”而是更偏重基础扎实度、工程习惯、数据库设计能力以及你对企业级应用开发的理解。这一点和用友的业务属性是强相关的。做企业软件的公司最怕的不是候选人不会某个偏门算法而是写出来的代码在生产环境里跑不稳、数据算不对、多人在线时拖垮服务。所以笔试题的考察重心会明显偏向Java核心基础、集合类原理、SQL与数据库设计、多线程与并发、JVM基础外加一两道算法题来摸底逻辑思维。这篇文章我就以这套笔试题目为线索结合我自己当年复习和后来面试别人时看到的情况把每类题目的考察目的、难点、答题思路以及我踩过的坑和后来总结出来的教训一次性聊透。无论你是正在准备校招、社招换坑还是已经在写业务代码想补一补基础这篇内容应该都比单纯搜一份“笔试题答案”更有价值。2. 题型构成与考察方向拆解2.1 选择题范围广但深度有限拼的是平时积累用友这套笔试题的选择题部分覆盖了Java基础语法、面向对象、异常处理、集合类、IO流、多线程基础、数据库SQL、计算机网络常识等。单题难度不算大但胜在范围宽很容易考出“你到底是真学过还是背过面试题”的区别。举个例子这类题目里很常见的考点是String、StringBuilder、StringBuffer的区别。看着简单但真正能答清楚的人并不多。很多人只会说“String不可变StringBuilder效率高”但问到为什么不可变、StringBuffer和StringBuilder到底差在哪里、字符串常量池的作用范围就卡壳了。这种题就是典型的“基础不牢地动山摇”型考点。还有一些网络基础题比如TCP三次握手、四次挥手的状态变化HTTP的几种请求方法区别这些在选择题里出现频率很高。对做后端开发的人来说这些是逃不掉的底层知识哪怕你平时写代码很少直接碰Socket但理解这些机制对你排查线上问题、设计接口、处理超时重试都很有帮助。我当时复习选择题的策略很简单把Java基础、集合、JVM、并发、MySQL、网络这几块核心知识做成思维导图每个知识点都要能讲出“是什么、为什么、怎么用、有什么坑”而不是只看结论。用这种方法过一遍选择题基本不会成为失分点。2.2 简答题考察“能不能把话说明白”简答题部分用友那几年常考的有这么几类类的加载机制、JVM内存模型、HashMap的底层实现原理、线程池的核心参数和执行流程、事务的ACID特性和隔离级别、索引的底层数据结构等。这类题目的评分标准和很多人想象的不一样——不是看你有没有背到标准答案而是看你能不能把逻辑链条讲完整。比如问HashMap底层实现只回答“数组加链表”只能拿一半分。完整的回答路径应该包含为什么用数组O(1)查找、为什么会出现哈希碰撞、链表和红黑树分别解决什么场景的问题、什么时候转化链表长度达到8且数组长度达到64、扩容机制resize的触发条件和数据迁移方式、为什么JDK 1.8要把头插法改为尾插法循环链表问题。我在复习简答题的时候特别推荐一个方法用费曼学习法把自己当成面试官用嘴把每个知识点完整讲出来讲到能说服自己为止。这个方法看起来有点傻但非常有效。因为很多知识点你眼睛看着会嘴上一讲就发现逻辑是断的这就是真正的薄弱点。2.3 编程题手写代码的熟练度和思路展示编程题部分用友这套题出现过的类型大致有单例模式手写懒汉、饿汉、双重检查锁、静态内部类、排序算法快排、冒泡、归并、链表反转、二叉树遍历、字符串处理类题目、以及一些简单的动态规划。不要小看这些看似“基础”的题目。手写单例模式看起来简单但能一次写对双重检查锁的人比例并不高。volatile关键字加不加、为什么加、synchronized加在方法上还是代码块上、锁的细粒度怎么控制这些都是实打实的考察点。我对编程题的建议就一条不要只会在IDE里写要能在一张白纸上或者一个空白编辑器里把代码完整写出来并且能自己解释每一行代码的作用。练到这种程度考试的时候才不会因为紧张而手抖漏掉关键代码。3. 几道高频核心题的精讲3.1 经典考点HashMap的底层实现与并发问题HashMap在Java笔试题里的出现频率可以说仅次于“自我介绍”和“你有什么缺点”。用友这道题从2017年考到现在核心逻辑一直没有变。首先要明确JDK 1.8及以后的HashMap底层是“数组 链表 红黑树”的结构。数组的每个位置是一个桶bucket通过key的hash值经过扰动函数处理后用(n - 1) hash计算存储位置。为什么要用(n - 1) hash而不是hash % n因为当n是2的幂次方时位运算(n-1) hash和取模hash % n的结果是一样的但位运算的性能更高。这里就是考察“能否从性能角度理解设计细节”的点。链表什么时候转红黑树两个条件同时满足链表长度达到8且数组长度达到64。为什么是8这是基于泊松分布的数学计算在负载因子0.75的情况下链表长度达到8的概率已经低到千万分之一级别。引入红黑树的目的是应对极端哈希冲突场景避免查询退化为O(n)。并发问题JDK 1.7的HashMap在多线程扩容时头插法可能导致环形链表get操作时会死循环。JDK 1.8改为尾插法从数据层面修复了这个问题但HashMap本身仍然不是线程安全的多线程写入仍然可能丢失数据。如果面试官问“有什么线程安全的替代方案”标准回答路径是Hashtable全表锁并发低、Collections.synchronizedMap包装类也是全表锁、ConcurrentHashMap分段锁/CAS局部锁并发能力强。3.2 线程池参数你真的理解corePoolSize吗ThreadPoolExecutor是Java并发包里的核心类也是用友这类企业级开发笔试的高频考点。这个类有七个构造参数但真正能讲透的人不多。核心参数有corePoolSize核心线程数、maximumPoolSize最大线程数、keepAliveTime非核心线程空闲存活时间、unit时间单位、workQueue任务队列、threadFactory线程工厂、handler拒绝策略。这里有一个比较深入的问题当一个任务提交给线程池时执行顺序是什么很多人会背“先核心线程、再队列、再非核心线程、最后拒绝策略”但对“队列什么时候开始接收任务”理解不到位。准确的流程是当前线程数小于corePoolSize时新建线程执行任务线程数达到corePoolSize后任务进入workQueue排队队列满且线程数小于maximumPoolSize时创建非核心线程执行任务队列满且线程数已经达到maximumPoolSize时触发拒绝策略。关键点在于核心线程被占用后不是立刻创建新线程而是先把任务塞队列。只有队列也满了才拉满线程数。这个设计和很多人直觉不一样但非常重要。拒绝策略有四种AbortPolicy直接抛异常、CallerRunsPolicy调用者线程执行任务、DiscardPolicy静默丢弃、DiscardOldestPolicy丢弃最老的任务。实际开发中CallerRunsPolicy比较常用因为这种策略下任务不会被丢弃但会拖慢提交线程的速度起到一种自然限流的效果。补充一个工作中常遇到的情况线程池参数设置不合理导致线上服务频繁Full GC或者任务堆积。我见过很多团队把corePoolSize设置得很大比如20、50但实际机器配置跟不上结果线程切换开销惊人系统吞吐量反而下降。合理的做法是根据CPU核心数、任务类型CPU密集还是IO密集、峰值QPS来估算。CPU密集任务通常设置CPU核心数 1IO密集任务可以提高到CPU核心数 * 2甚至更高结合压测结果调优。3.3 SQL优化实战为什么你的SQL越写越慢用友做企业软件出身数据库设计几乎是笔试必考项。常见题目类型包括根据业务场景写SQL、给一个慢查询说优化思路、设计某业务模块的表结构。有一道典型的题目是这样的一张用户订单表数据量过了千万现在要查询某用户在最近30天内的订单记录SQL很慢怎么优化看到这种题先别急着说“加索引”。完整的思路应该是先看执行计划确认慢在哪里全表扫描、临时表、文件排序等确认索引情况user_id和order_time是否有联合索引最优方案是创建(user_id, order_time)的联合索引注意字段顺序是等值查询在前、范围查询在后避免在索引列上使用函数或隐式类型转换考虑分页查询的深翻页问题用游标方式代替大偏移量limit如果表数据量实在太大考虑按时间分表或归档历史数据。这里有一个细节非常值得展开联合索引的最左前缀原则。如果查询条件是where user_id ? and order_time between ? and ?创建(user_id, order_time)联合索引后MySQL会先按user_id精确定位再在命中的范围内按order_time走索引排序效率非常高。但如果你把索引建成了(order_time, user_id)那这条查询就完全用不上索引了因为最左前缀列是order_time在order_time不等值的情况下user_id的过滤条件无法走索引。这是很多人的认知盲区也是SQL优化题的高频埋坑点。对应到实战场景做报表查询或者后台管理系统的列表页时这种慢SQL几乎是必踩的坑。我的经验是每个列表查询都应该根据实际的筛选条件组合预先设计好对应的索引而不是等线上告警了再临时补。4. 实操环节用一份“模拟答题卷”还原考试现场4.1 从读题到落笔编程题的答题节奏控制我见过很多同学在笔试的编程题环节折戟不是不会做而是时间分配崩了。用友这套题编程题一般是两道一道偏数据结构一道偏实际应用建议时间控制在25分钟以内留出时间检查前面的选择题和简答题。拿到一道编程题正确的读题顺序是第一步明确输入范围和约束条件第二步确认输出格式第三步在纸上写测试用例第四步确定算法的时间和空间复杂度第五步才动手写代码。举个例子如果题目是“实现一个函数将字符串中的每个单词反转但是单词之间的相对顺序不变”很多人上来就写结果漏掉了“String是不可变的每次拼接会创建新对象”这个点。用StringBuilder或者直接把字符串拆成char数组原地操作才是面试官期望看到的解法。写代码的时候我习惯先写出关键方法的签名和主干逻辑再补细节。比如写快排先把partition函数想清楚再考虑递归终止条件这样框架不乱不会写到一半卡住。另外一个很现实的建议先保证能跑通再去优化性能。在笔试平台上编译通过并且样例通过至少能拿到一半以上的分而一个完美的思路但编译不通过的答案往往是零分。4.2 简答题的“三段式”答题法简答题想要拿高分我总结了一个三段式结构先下定义再讲原理/流程最后说应用场景或注意事项。拿“请简述JVM内存模型”这道题来说低分答案是直接把各类内存区域的名字罗列一遍堆、栈、方法区、程序计数器、本地方法栈然后解释一句“堆存对象栈存引用”。这种答案太单薄。高分答案的思路应该是首先说明JVM内存模型是“线程共享”和“线程私有”两大块线程共享部分包括堆和方法区JDK 1.8之后方法区被元空间取代堆是对象实例分配的主要区域元空间使用本地内存不受堆大小限制线程私有部分包括虚拟机栈、本地方法栈、程序计数器。虚拟机栈里的栈帧对应一次方法调用包含局部变量表、操作数栈、动态链接、方法出口最后补充一条实际应用栈溢出StackOverflowError和堆溢出OutOfMemoryError的触发条件以及调优时如何通过-Xmx、-Xms参数控制堆大小通过-Xss控制栈大小。这样的回答逻辑链条完整深度也有面试官一眼就能看出你是真的理解而不是背了答案。4.3 数据库设计题的踩坑点第一范式到第三范式不是背出来的有一类题目是“设计一个简单的员工-部门-薪资记录表结构”看起来简单但里面埋了很多坑。比如员工和部门的关系是一对多还是多对多一个员工是否可能同时在多个部门任职在ERP系统里这种兼职场景很常见薪资记录要不要保留历史版本还是只保留当前值在实际的表结构设计中很多人犯的错是为了“简化”而丢失了关键的业务约束。比如薪资字段直接用DECIMAL(10,2)存储但没有考虑历史追溯的需求。在企业软件里薪资调整记录、部门调动记录都是必须保留审计轨迹的如果一开始设计时就忽略了后面返工的代价极大。笔试答题的时候最好把设计思路分为几步来展示画出核心实体和关系可以用文字描述关联关系列出每个表的字段、类型、是否允许为空说明主外键设计、唯一约束、索引策略补充一条站在业务角度上哪些字段需要加冗余来提升查询性能哪些字段必须拆表保证数据一致性。这个过程不仅是在答题也在展示你对企业级软件设计的理解。而这恰恰是用友这类公司特别看重的。5. 避坑指南那些年我踩过的笔试大坑5.1 编译器开挂一时爽笔试题上一脸懵很多同学平时写代码太依赖IDE的自动补全、快捷键、语法提示到了笔试环境尤其是不带IDE的在线编辑器就感觉双手被绑住。有一个挺典型的例子写一个线程安全的单例IDE里new对象、synchronized、volatile都是自动补全的谁都会。但到了笔试平台要自己一行一行敲出来很多人就会漏掉最关键的一步——双重检查锁为什么要加volatile。不加volatile由于指令重排序某线程可能拿到一个“未完全初始化”的对象这在并发场景下是致命bug。这里解释一下原理instance new Singleton()这行代码在JVM层面不是原子操作它分成三步——分配内存、初始化对象、将引用指向内存。如果不加volatile第二步和第三步可能被重排序导致一个线程读到引用非null但对象还未完成初始化的内存拿到一个半成品对象。这个知识点我强烈建议每个准备笔试的人都要亲手写一遍并且能清晰地讲出原因。因为它在简答题、编程题、面试聊方案三个环节都可能出现。5.2 集合类的“线程安全”误区只要问到集合类十个候选人里五六个都会说“Vector是线程安全的”然后就没有然后了。这句话不能说错但远不够。你会追问自己吗Vector为什么线程安全因为它的每个方法都用synchronized修饰但这也意味着粒度过大并发性能很差所以现在实际上很少使用了。更值得了解的是Collections.synchronizedList、CopyOnWriteArrayList、ConcurrentHashMap各自的适用场景。CopyOnWriteArrayList适用于读多写极少的场景。它每次修改都是复制整个底层数组写操作代价很高但改的时候读线程不需要加锁所以读性能极高。如果你在面试中说“我在一个缓存场景里用CopyOnWriteArrayList存配置信息因为配置更新非常少但读取非常频繁”这就是一个加分回答因为体现出了根据场景选型的能力。5.3 复习资料贵精不贵多我给一个非常真心的建议不要收集几十个G的笔试资料然后每个都看两眼就扔。笔试复习最好的方式是“做真题 精读一本基础书 反复画逻辑图”。我当时复习的时候只用了Java核心技术卷一、MySQL技术内幕、以及网上能找到的历年校招真题配合自己整理的笔记效果比刷一大堆教程好得多。每次做完一套真题把错题按“知识点”归档然后逐个击破。比如发现HashMap的底层原理答不全就花一天时间把这个知识点彻底搞透再看看相关的二叉树、HashTable、ConcurrentHashMap形成知识网络而不是孤立地背答案。6. 常见问题与排查技巧实录问题我当时犯的错正确的处理方式选择题里Java集合和HashMap的题错了只记得“数组链表”没有掌握红黑树转换条件和扩容细节把源码级别的实现逻辑完整走一遍用画图方式理解数据结构变化简答题JVM内存模型答得太单薄只罗列内存区域名没有说明各区域作用、异常场景、调参方法按“是什么-原理-实际应用”三段式组织答案配合画内存布局图手写线程池参数时漏掉了两种常见拒绝策略只知道抛异常和丢弃不会讲CallerRunsPolicy和DiscardOldestPolicy每个策略结合一个实际调度场景理解比如调用者执行策略适合限流数据库慢SQL优化题答不到点子上直接说“加索引”没有分析索引结构和查询条件匹配先看执行计划、分析查询条件、设计联合索引、再考虑分表和归档编程题没控制好时间第一题磨蹭太久第二题没时间写先扫一遍所有题的难度先易后难编程题超过25分钟就先放下上面这个问题表相信很多人看着眼熟。这些坑不是“只有不够细心才会踩”而是没有掌握正确的知识组织方式导致的全盘崩溃。准备笔试的过程本质上是把零散知识点串成能力体系的过程。如果时间紧张我的建议是优先把这几个方向学透Java集合类尤其是HashMap和ConcurrentHashMap、JVM内存与垃圾回收、线程池和常用并发工具类、MySQL索引与事务隔离级别、Spring的IOC和AOP原理。这五个方向基本上覆盖了用友这类企业级公司笔试题的八成以上考点。7. 笔试之后这套题对实际工作的影响很多人觉得笔试题考完就完了和实际工作关系不大但我个人体会正好相反。用友这套题里涉及的很多知识点在我后来做企业级项目开发时反复被用到。单例模式看起来是个八股文考点但你在写配置管理工具、连接池对象、Spring Bean默认作用域的时候天天和单例打交道。理解它的线程安全性能帮你避免很多线上的“灵异问题”——比如多环境下配置读取不一致、共享状态被并发修改等。SQL优化题也不是纸上谈兵。一个实际的企业应用数据量一旦过了千万级SQL写得好不好性能差距是几十倍的。我在项目里见过一条查询因为没走索引导致数据库CPU飙升、接口响应从20ms退化到3s的线上事故。当时排查的时候第一个动作就是看执行计划和笔试题目里的思路完全一致。线程池更不用说了。企业应用的后端服务几乎都是用线程池处理HTTP请求的。什么时候调核心线程数、要不要用有界队列、拒绝策略选哪个这些决策直接影响系统的稳定性。所以别把笔试当成一场应试它是一个很好的“能力体检”。通过一套好题目你可以清楚看到自己哪些基础牢固、哪些只是看似牢固。用这种心态去准备和复盘收获会大很多。最后再分享一个我自己体会特别深的小技巧每次做完一套真题不要急着对完答案就扔花半小时在纸上画一张“这套题考了哪些知识点”的思维导图标出自己拿不准的地方然后针对性地补。这个方法坚持一个招聘季你的知识体系会比以前扎实非常多。祝看到这里的同学都能拿到心仪的offer。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
