企业官网建设流程全解析

每年秋招，星环科技的笔试在大数据求职圈里都是绕不开的话题。作为国内少数能打通“数据库+大数据平台+AI”全栈基础软件的公司，它的笔试题风格和纯互联网大厂有明显区别——不会只考LeetCode或者纯粹的Java八股，而是更看重分布式系统原理、组件工作机制、数据库底层逻辑这些工程向的硬功夫。选择题部分尤其这样，覆盖面广、细节抠得深，很多同学在牛客和社区里吐槽“看着都眼熟，就是选不对”。

这份标题里的“2024年星环科技秋招笔试选择题集合”，我根据近两年参加笔试的同学反馈、技术社区讨论，以及我对这家公司技术栈的理解，把这些选择题整理成了带解析和避坑说明的分类笔记。不论你是今年准备投递星环，还是打算拿它当一次分布式系统和大数据基础的自测，这篇内容都可以直接用起来。

1. 星环笔试题型与宏观考点分布

1.1 整体题型结构与时间分配

星环的秋招笔试在线测评一般分为两部分：第一部分是行测/性格测评，第二部分才是技术笔试。技术笔试中选择题通常占大头，一般有20到30道单选和多选，后面可能跟1到2道编程题或简答题。选择题覆盖范围非常稳定，基本就是Java基础、数据库原理、分布式系统、大数据组件、Linux和计算机网络这几个版块。

时间上，选择题部分给的时间看起来宽裕，但实际做起来非常紧张。原因是每道题的信息量都不小，尤其涉及组件原理的题目，题干里经常故意埋“混淆项”，比如把Flink的Checkpoint机制和Spark的Checkpoint混在一起考。我个人的经验是，选择题部分每道题控制在1.5分钟内，拿不准的先按第一印象选，标记之后回头再看，绝对不要在单道题上死磕。

提示：星环的笔试系统支持题目标记和回看，一定要善用这个功能。多选题目宁少选不错选，因为一旦选错一个选项整题零分。

1.2 考点权重与Java/大数据倾向分析

从刷题统计来看，选择题的考点权重不是平均分配的。Java基础和多线程并发大概占30%，数据库和SQL占20%，分布式系统和一致性协议占15%，大数据组件（Hadoop/Spark/Flink）占20%，Linux和网络占15%左右。这个分布很能说明问题：星环作为基础软件公司，最看重候选人是否理解并发编程的底层逻辑，以及能否准确理解分布式系统的核心问题。

还有一个明显的倾向：Java考题倾向于“原理级细节”，大数据组件考题倾向于“机制级应用”。比如Java部分会考ConcurrentHashMap在JDK 8下的锁粒度，大数据部分会考HDFS写入时Pipeline的ACK确认过程。这些内容只看面经不亲自动手验证，很难答得准。

这个分布给我们的备考信号非常明确：刷题时不要平均用力。Java并发和数据库索引是性价比最高的两座山头，先攻下它们，选择题基本能拿下一半分数。

2. Java基础与并发高频选择题精析

2.1 HashMap与集合框架的经典陷阱

星环选择题中，集合框架的考点集中在HashMap、ConcurrentHashMap、ArrayList这几个类上，而且很多题目都围绕“JDK版本差异”和“扩容机制”这两个维度展开。比如这道考察频率极高的题：

单选题：在JDK 8中，HashMap当链表长度达到多少且数组长度大于64时，链表会转换为红黑树？ A. 6 B. 7 C. 8 D. 16

正确答案是C。JDK 8的HashMap在链表长度达到8时会触发树化，但前提是HashMap的数组长度（桶数组容量）不小于64。如果数组长度还不到64，即使链表已经很长，也会优先选择扩容而不是树化。这个前提条件经常被很多复习资料漏掉，笔试就专门考这一点。

关于阈值为什么是8，源码注释里有解释。理想情况下随机hashCode算法下，桶中节点数量服从泊松分布，链表长度达到8的概率已经非常低（约千万分之六）。选8是为了在时间和空间成本之间做平衡，避免树化过于频繁，也防止链表过长导致的查询性能退化。

单选陷阱题：在JDK 8中，关于ConcurrentHashMap的说法正确的是？ A. 使用Segment分段锁实现线程安全 B. 读操作需要加锁 C. 使用CAS + synchronized 实现线程安全 D. 不允许存储null键，但允许存储null值

这道题正确答案是C。JDK 8的ConcurrentHashMap放弃了Segment分段锁，改为对数组桶的头节点进行synchronized加锁，配合CAS操作实现线程安全。读操作依靠volatile修饰的节点数组和节点内的val字段保持可见性，不需要加锁。D选项也是干扰项，ConcurrentHashMap的键和值都不允许为null，这一点和HashMap不同。

这里有个容易搞混的知识点：为什么ConcurrentHashMap不允许null值，而HashMap允许？因为这个类用在多线程环境下，如果get方法返回null，你无法判断是“这个key不存在”还是“这个key对应的value本身就是null”，这会导致歧义。而HashMap是单线程环境下使用，不存在这种并发歧义问题，所以允许null。

2.2 JUC并发编程必考知识点

线程池和AQS是星环Java选择题里几乎必考的环节。下面这道关于线程池的题目，是我看到多个同学反馈在考试中遇到的同类题。

单选题：ThreadPoolExecutor中，当核心线程数已满且阻塞队列已满时，提交新任务会触发什么机制？ A. 直接执行该任务 B. 抛出RejectedExecutionException异常 C. 创建非核心线程执行该任务 D. 丢弃该任务

正确答案是B。需要区分两个阶段：当核心线程数未满时，新任务会创建核心线程执行；当核心线程已满，但阻塞队列未满时，任务会进入队列等待。只有当核心线程数满、队列也满、当前线程数已经达到最大线程数时，才会触发拒绝策略。默认的AbortPolicy会抛出RejectedExecutionException。

很多备考同学在这里背得不仔细，把“队列满之后创建非核心线程”记成“直接拒绝”，导致失分。实际执行顺序是：corePoolSize满了先进队列，队列满了才尝试创建非核心线程，非核心线程数也达到maximumPoolSize时，才会执行拒绝策略。这四步顺序就是线程池执行任务的完整逻辑，一定要记牢。

多选题：关于AQS（AbstractQueuedSynchronizer）的描述，正确的有？ A. AQS通过volatile int类型的state变量来表示同步状态 B. ReentrantLock的公平锁和非公平锁都基于AQS实现 C. CountDownLatch的计数器实现依赖AQS的共享锁 D. Semaphore允许多个线程同时访问临界资源

这道题四个选项都是对的。A选项是AQS的核心数据结构——state变量是volatile修饰的int，保证多线程间的可见性。B选项ReentrantLock内部有一个Sync类继承AQS，FairSync和NonfairSync都是Sync的子类。C选项CountDownLatch内部确实用AQS的共享锁机制实现。D选项Semaphore本质上就是共享锁的计数控制。

这里再补充一个常考的细节：Semaphore获取许可时，公平模式和非公平模式的区别在于是否调用hasQueuedPredecessors()方法检查等待队列中是否有其他线程。很多入门资料对这个点讲得含糊，笔试选择题偶尔会在这里埋选项。

3. 数据库与SQL笔试选择题实战

3.1 索引失效场景与优化选择题

数据库部分是星环笔试选择题中技术含量较高的一块，题目很务实，就像在日常开发中真的会遇到的问题。索引失效场景是绝对的高频考点，基本每次考试都有2到3道。

单选题：有表 student(id, name, age, class_id)，在 name 列上建立了普通索引。下列哪个查询条件会导致索引失效？ A. WHERE name = '张三' B. WHERE name LIKE '张%' C. WHERE name LIKE '%张' D. WHERE name IN ('张三', '李四')

正确答案是C。LIKE查询中，如果通配符%出现在关键词的开头，那么B+树索引就无法利用前缀匹配特性来定位数据，只能进行全表扫描，所以索引失效。A选项是等值匹配，索引正常生效；B选项虽然是模糊查询，但通配符在尾部，仍然可以使用索引的前缀匹配；D选项的IN查询在MySQL优化器中通常可以转换为多个等值条件的组合，索引可以生效。

这个知识点看起来简单，但考试中还会变着花样考，比如“%张%”和“张%”的区别、函数包裹索引列（如WHERE LEFT(name,1) = '张'）导致失效等。核心原理是：索引列参与了函数运算或隐式类型转换时，优化器无法使用索引列原本的有序结构来加速查找。

再补充一个经常出现的选择题方向：联合索引的最左前缀原则。

多选题：对于联合索引 (a, b, c)，下列哪些查询能命中该索引？ A. WHERE a = 1 AND b = 2 B. WHERE b = 2 AND c = 3 C. WHERE a = 1 AND c = 3 D. WHERE a = 1 AND b = 2 AND c = 3

正确答案是A和D。C选项只能使用a列这一个索引前缀，c列无法利用索引，因为b列这个中间列没有参与等值匹配。这里要说明的是，C选项中a列仍然能用到索引，只是c列不能利用索引进行过滤，所以这道题如果考“完全命中”和“部分命中”要看清题目表述。B选项完全无法使用该联合索引，因为缺少最左列a的约束。

这类题目的核心判断标准只有一条：查询条件的列顺序是否从联合索引最左列开始连续覆盖。中间跳跃没问题（如a和c），但跳跃之后的列（c）无法利用索引。

3.2 事务隔离级别与MVCC选择题

事务隔离级别的选择题在星环笔试中也很常见，而且特别喜欢结合MySQL的默认隔离级别来考。

单选题：MySQL InnoDB 引擎默认的事务隔离级别是什么？在该隔离级别下，可以解决哪类并发问题？ A. 读未提交，可以解决脏读 B. 读已提交，可以解决不可重复读 C. 可重复读，可以解决幻读 D. 串行化，可以解决所有并发问题

正确答案是C。MySQL InnoDB默认的隔离级别是可重复读（Repeatable Read），在这个级别下，通过MVCC多版本并发控制机制，快照读可以避免不可重复读和幻读；通过间隙锁（Gap Lock）和临键锁（Next-Key Lock），当前读也可以在很大程度上解决幻读问题。

这个题的干扰点在于：很多同学只知道“可重复读”会存在幻读问题，这是从SQL标准角度说的。但InnoDB在可重复读级别下，利用间隙锁确实能解决大多数幻读场景。星环的题考的就是这个深度——不仅知道默认级别是什么，还要知道该级别下哪些问题被解决了。

MVCC也是必考内容，它核心就是三个隐藏字段和ReadView机制。

多选题：关于InnoDB MVCC的隐藏列，以下说法正确的有？ A. DB_TRX_ID 记录最后修改该行记录的事务ID B. DB_ROLL_PTR 指向该行记录的undo log C. 每个隐藏列占用6字节 D. 隐藏列对用户不可见，但可以通过SELECT显式查询

正确答案是A和B。C选项不对，DB_TRX_ID和DB_ROLL_PTR各占6字节是InnoDB早期版本的实现细节，后期版本引入了DB_ROW_ID，结构上有调整，笔试以官方文档为准通常不会把“每个隐藏列都占6字节”这种绝对化表述作为正确选项。D选项中，隐藏列确实对用户不可见，也不支持通过SELECT去显式查询它们。

这里要提醒一个备考误区：MVCC不是一种单独的技术，而是“多版本数据存储+ReadView判断可见性”的组合。每次更新一行记录，旧版本会写入undo log，并通过回滚指针串成版本链。查询时通过ReadView判断当前事务能看到哪个版本的数据。这个机制理解了，事务隔离级别的选择题基本都能推导出来。

4. 大数据核心组件原理选择题拆解

4.1 HDFS与MapReduce原理选择题

大数据组件部分是星环笔试最有辨识度的环节，它考的不是组件API怎么用，而是真正的运行机制。HDFS的写入流程是每年必考的重点。

单选题：客户端向HDFS写入一个文件时，DataNode之间数据块复制的Pipeline传输顺序是？ A. 客户端→DataNode1→NameNode→DataNode2 B. 客户端→DataNode1→DataNode2→DataNode3 C. 客户端→NameNode→DataNode1→DataNode2 D. 客户端→DataNode1→DataNode2→NameNode

正确答案是B。HDFS写入过程的完整链路是：客户端先向NameNode请求上传文件，NameNode返回可用的DataNode列表；然后客户端将数据按块（默认128MB）分为多个packet，以Pipeline的方式依次传给第一个DataNode，再由第一个DataNode传给第二个、第三个，形成串行复制链路。每级DataNode收到数据包后都会向上一级发送ACK确认，形成反向的应答链路。

关于ACK机制的考察也有一个经典选择题：HDFS写入时，客户端在什么情况下认为一个数据块写入成功？答案是“Pipeline中所有DataNode都返回ACK确认”。这里有个容易混淆的细节：NameNode不参与实际数据的传输，它只负责元数据管理。有些资料上讲的“DataNode向NameNode汇报块信息”是异步心跳汇报机制，不是写入确认机制，考试中经常把这两者放在同一个选项里作为干扰项。

MapReduce部分的常考题集中在Shuffle阶段。

单选题：MapReduce中，Map端输出的KV数据在写入环形缓冲区时，默认缓冲区大小和溢写阈值分别是多少？ A. 128MB, 80% B. 100MB, 80% C. 64MB, 80% D. 100MB, 70%

正确答案是B。MapTask的环形缓冲区默认大小是100MB，当缓冲区使用率达到80%时，后台线程开始将数据溢写到本地磁盘。这个80%阈值设计的原因值得理解：不能等100MB全部写满才开始溢写，否则Map端还在持续产生输出数据，缓冲区没法腾出空间，可能导致线程阻塞。保留20%的余量是给溢写期间继续写入的数据留缓冲空间。

这里还有一个细节经常考到：溢写过程中，数据会进行分区（partition）、排序（sort）和可选合并（combiner），然后写入磁盘生成临时文件。多个临时文件在MapTask结束时会合并成一个最终输出文件。Reducer端拉取数据后，还会进行归并排序和分组。整个Shuffle过程是MapReduce面试题的核心，也是选择题的多发区。

4.2 Spark与Flink选择题高频要点

这两年星环笔试中，Spark和Flink的题目占比明显上升，这和星环自研的分布式计算平台产品线相关。Spark的常考方向是RDD依赖关系和宽窄依赖判断。

单选题：下列哪个算子会产生宽依赖？ A. map B. filter C. groupByKey D. union

正确答案是C。宽依赖（Shuffle依赖）是指父RDD的每个分区被子RDD的多个分区使用，也就是说子RDD的每个分区依赖父RDD的多个分区，需要跨节点进行数据重排。groupByKey因为要把相同key的数据汇聚到同一个分区，必然触发Shuffle，属于宽依赖。map和filter是一对一的窄依赖，父RDD的每个分区最多被子RDD的一个分区使用。union操作生成的RDD每个分区只依赖父RDD中对应的一个分区，也是窄依赖。

更进阶的考法是让判断“宽依赖和窄依赖对容错的影响”。窄依赖下，某个分区数据丢失时，只需要重新计算父RDD的对应分区即可；宽依赖下，一个分区丢失可能导致父RDD多个分区需要重新计算，容错代价更大。Spark的Lineage容错机制就依赖这个概念。

Flink部分最常考的是Checkpoint和状态一致性。

多选题：关于Flink的Checkpoint机制，以下描述正确的有？ A. Checkpoint是Flink实现状态容错的核心机制 B. 开启Checkpoint后，Flink会定期对状态进行快照 C. Checkpoint过程依赖Barrier在数据流中传播 D. Checkpoint数据默认只存储在JobManager内存中

正确答案是A、B、C。D选项不正确，Checkpoint的快照数据默认存储位置可以通过state.backend配置修改，生产环境通常使用HDFS或其他分布式存储，不会只放在JobManager内存里，因为JobManager内存容量有限且自身也可能故障。

关于Barrier的理解是很多考生的难点。简单来说，Barrier是Flink在数据流中注入的一种特殊标记，它携带着Checkpoint ID。当某个算子收到所有输入源发送的对应该ID的Barrier时，就说明该算子在这个ID之前的数据都处理完了，可以对该算子的状态做一次快照。这个过程被称为“异步屏障快照”（ABS算法），Flink的Checkpoint机制基于它实现。

Flink重启策略的选择也是一个常见考点。固定延迟重启、失败率重启和指数延迟重启的区别，选择题里经常考“无恢复策略”（NoRestartStrategy）适合什么场景。记住一个原则：生产环境一般不用无恢复策略，除非任务失败后需要人工介入的场景才考虑。

5. 分布式系统与计算机网络选择题

5.1 CAP定理与一致性协议选择题

分布式系统原理是星环笔试选择题中最能拉开差距的部分。很多写业务代码的同学对CAP定理的记忆停留在“三选二”这种粗暴归纳上，但星环的题会问得更细。

单选题：在CAP定理中，当网络分区发生时，如果系统选择保证可用性（A），那么系统在分区恢复前无法保证什么？ A. 分区容错性 B. 一致性 C. 可用性 D. 持久性

正确答案是B。CAP定理的完整表述是：在分布式系统中，一致性、可用性和分区容错性三者不可兼得。当网络分区发生时，系统必须在一致性和可用性之间二选一。如果选择可用性，意味着每个节点都继续对外提供读写服务，但不同节点上的数据可能出现不一致，所以无法保证一致性。这个题的重点在于：分区容错性不是“可选”的，在分布式环境中网络分区是物理现实，所以实际取舍发生在一致性和可用性之间。

除了CAP，BASE理论也是常客。BASE强调基本可用（Basically Available）、软状态（Soft State）和最终一致（Eventually Consistent）。考试经常把BASE和ACID放在一起考对比。

还有一类高频题是Raft协议和Paxos协议的对比。

多选题：关于Raft协议，下列描述正确的有？ A. Raft将一致性协议拆分为领导者选举、日志复制、安全性三个子问题 B. Raft中每个任期（Term）内最多只有一个领导者 C. 日志复制中，领导者将日志条目发送给跟随者，超过半数的跟随者确认后才提交 D. Paxos协议比Raft协议更容易理解和实现

正确答案是A、B、C。D选项恰恰说反了，Raft设计初衷就是为了降低Paxos的理解难度，通过将问题拆分成独立子问题和强领导者模型，让协议更容易落地实现。Raft中同一任期内的领导者是唯一的，通过随机超时机制来触发选举，避免多个节点同时竞选造成脑裂。日志复制遵循“过半确认提交”原则，确保已提交的日志在多个节点上都有副本。

这里从笔试角度补充一个细节：Raft选举过程中，候选人获得的票数必须超过半数（而不是等于半数），才能成为领导者。如果集群总节点数是3，候选人至少需要2票；如果是5节点集群，至少需要3票。这个“严格大于N/2”的条件，我在多选题里见过好几次。

5.2 Linux与网络基础选择题

Linux在星环笔试中的占比不算特别高，但出现的题目都很实用，基本是判断日志文件大小、查找进程、查看端口这些生产环境常用命令。这类题的难点不在命令本身，而在于选项之间非常相似。

单选题：哪个命令可以实时查看Java进程的GC日志输出？ A. tail -f gc.log B. cat gc.log C. head -100 gc.log D. vim gc.log

正确答案是A。tail -f会持续追踪文件末尾的新增内容，适合实时监控GC日志。cat是一次性输出全部内容，head只查看文件开头部分，vim虽然是交互式编辑器但无法做到自动刷新。这个题表面考命令，实际上也在考候选人是否真有排查线上问题的经验。

netstat和ss命令的区别也是高频考点。现在很多新系统上netstat已被ss替代，选项里如果出现“ss -tlnp可以查看监听端口对应的进程PID”，这个说法是正确的。Linux进程和内存这块，top命令中各个字段的含义也有被考到，重点关注LOAD平均值和CPU使用率的区别。

计算机网络部分的题目集中在TCP握手和HTTP协议。

单选题：TCP三次握手中，第二次握手时服务器发送给客户端的报文标志位是什么？ A. SYN B. ACK C. SYN + ACK D. FIN

正确答案是C。TCP三次握手的过程是：客户端发送SYN报文请求建立连接；服务器收到后，回复SYN+ACK报文，表示“我收到了你的同步请求，并且我也同步给你”；客户端再回复ACK报文确认。第二次握手如果只选ACK就是漏了关键信息，因为服务器还需要同步自己的初始序列号，所以必须带上SYN标志。

HTTP部分，星环的题喜欢结合RESTful API风格来考，比如GET、POST、PUT、DELETE的语义区别，以及HTTP状态码的含义。一个典型的例子是区分201 Created和200 OK的区别，POST请求成功创建资源时返回201是更规范的写法。还有状态码301（永久重定向）和302（临时重定向）的区别也是常考点。

注意：网络题虽然每场考试只有2到4道，但性价比很高。TCP握手、HTTP状态码这些内容非常固定，只要系统过一遍就基本能拿满分，不要因为觉得简单就忽略。

6. 备考建议与复盘心得

6.1 考前一个月的刷题路线

如果你还有一个月左右的时间准备星环笔试，我的建议是不要盲目去刷海量题库，而是按模块分三步走。

第一周主攻Java基础和并发。把HashMap、ConcurrentHashMap、线程池、AQS、synchronized和ReentrantLock的对比这些核心知识点过一遍。学习方式以源码阅读配合选择题练习为主，比如看完HashMap的put方法源码，再去做链表转红黑树的题目，理解会深很多。

第二周主攻数据库和分布式原理。数据库部分重点看索引原理和事务隔离级别，建议在本地MySQL环境把联合索引和最左前缀原则亲手验证一遍——创建一个三列联合索引，用EXPLAIN看不同查询的key_len，这样印象会很深刻。分布式部分重点看Raft协议和CAP定理，Raft可以结合动画演示网站去理解领导者选举和日志复制的完整流程。

第三周主攻大数据组件和整体模拟。HDFS写入流程、MapReduce Shuffle、Spark依赖关系、Flink Checkpoint，每个组件花一两天过一遍原理图，然后做整套模拟题。模拟时严格计时，重点训练多选题的“宁缺毋滥”策略。

6.2 笔试现场应试技巧

除了知识储备，考场上的策略也能明显影响分数。我个人总结了三条实际经验。

多选题先确定必对项再考虑不确定项。星环的多选题评分规则通常是全部选对才得分，少选不得分或得部分分要看当年的规则说明，但错选肯定零分。所以拿不准的选项尽量不选，保住有把握的选项是优先策略。

选择题做完后如果有时间，一定要回看标记过的题目。前面提到每道题控制在1.5分钟内，实际考试中很多题目读完题干和选项可能就要一分钟。如果一道题超过三分钟还没头绪，果断先选一个最可能的答案并标记，抓紧时间做后面的题。编程题或者简答题的分值通常高于选择题，不要在选择题上挤占过多时间。

还有一个容易被忽略的点：答题前先把笔试卷面浏览一遍。我会用前两三分钟快速扫所有选择题，把明显会的题先顺手选掉，把需要思考的题标记下来再逐题攻克，这样可以保证“会做的题都拿到分”。

另外提前熟悉星环的产品技术栈也有帮助。这家公司的核心产品线包括分布式数据库、大数据基础平台、数据科学平台等，笔试题目中组件原理类的选材经常会带有企业自身产品场景的影子。平时多了解这些产品在数据仓库、实时计算、数据治理等场景中的角色，对一些场景化选择题的理解会有帮助。

6.3 常见复习资料与避坑清单

根据我刷题和参加过考试的经验，有几份资料是备考星环笔试选择题时比较值得看的：Java并发编程实战、MySQL技术内幕InnoDB存储引擎、大数据技术原理与应用（厦门大学林子雨老师的公开课教材）、以及Flink官方文档的Checkpoint章节。这些资料比直接刷面经有效率得多，因为选择题考的是原理理解，不是死记硬背。

复习过程中有几个高频踩坑点需要提醒一下：

第一，不要只背结论不问原因。比如“HashMap链表长度到8转红黑树”这个结论，如果你不知道数组长度要达到64这个前提，遇到变体题就会翻车。再比如“可重复读隔离级别下可以解决幻读”这种表述，如果不知道InnoDB间隙锁机制，你可能会凭SQL标准教材内容去判它错误。

第二，不要混淆各组件中概念相近的机制。Spark的Checkpoint和Flink的Checkpoint、HDFS的ACK确认和Kafka的ACK机制、MapReduce的Combiner和Reducer的作用范围，这些内容很容易弄混。建议用表格对比记忆，把每个机制的核心目的、触发时机、执行位置三个维度整理清楚。

第三，不要忽略公司产品背景题。星环笔试的简答题或场景题偶尔会结合他们自己的产品（比如分布式数据库）来出题，选择题偶尔也会出现“下列哪个组件适用于实时流处理场景”这类开放性判断题。备考时留意一下业界常见组件选型对比（Kafka Streams vs Flink vs Storm）会有帮助。

在题型准备之外，还有一点想强调：心态。星环的笔试选择题覆盖面广，任何人都不可能每道题都答对，遇到不会的题太正常了。把自己会做的做对、不确定的尽量不选错，最终成绩就不会差。实际考试中，选择题拿到80%左右的正确率就是一个很有竞争力的成绩了。

最后再分享一个小观察——你在刷题过程中弄懂的那些底层原理，在面试中还会被继续深挖。星环的面试官很喜欢在笔试考点的基础上做追问，比如笔试题考了HDFS写入流程，面试可能会让你画出完整的时序图，并追问“如果某个DataNode在写入过程中宕机，客户端如何感知和处理”。所以准备笔试选择题的时候，不要以“选出正确答案”为终点，而是以“能跟别人讲清楚为什么”为终点，这样笔试和面试可以一起准备，效率会高得多。