type
Post
status
Published
date
Apr 7, 2025
slug
summary
tags
面试
硕士
category
技术
icon
password
实时系统优化
可以从任务调度、高可靠性和资源利用方面展开。比如调度进程的时候可以分配优先级，并且采用抢占式调度，让更紧急的任务提前执行。
内存优化 • 预分配内存池：避免动态内存分配导致的碎片和延迟。例如，在启动阶段为实时任务预留固定内存区域 • 大页内存（HugePage）：减少TLB缺失率，提升内存访问效率（适用于高频访问的数据缓冲区）
将ZNS用在云存储上
字节跳动做过相关的研究，实际上效果并不好。一方面，使用ZNS需要对软件栈做较大的修改，比如这个顺序写限制。那么对于现有的生态适配是一个挑战。第二个，就是ZNS本身的优化也有点虚。比如，他最原始的那篇文章中是将文件系统层次的GC也当作正常的IO带宽来算，因为盘并不知道文件系统的GC操作，而GC也就是把数据从盘上读出来再写到另一个地方去，那你带宽当然是大的。但是垃圾回收的带宽并不是用户真是想要的，所以ZNS的性能优化本身就是存疑的。第三点，ZNS将盘内管理的工作交给主机去控制，从某种程度来说是给主机增加了负担，因为盘上本身是有一个主控的。对于云服务来说更是这样，本身存储节点也有一定计算能力。那现在将这些结点上的计算能力浪费了。因此不是特别合适。但是我手机上没这个问题，因为手机上一方面用的本身是F2FS，他的管理方式本来就适合ZNS，不会因为使用ZNS额外增加开销。另一方面手机的UFS本身没有计算能力，确实比较适合ZNS。但是对于云服务来说，我看不是特别适合。
怎么解决多 CPU 下同时访问自旋锁的性能问题
无锁数据结构替代：对高频访问场景（如计数器），优先使用原子变量或无锁队列
混合锁策略：对长临界区代码切换为互斥锁（如pthread_mutex），避免CPU资源浪费
读写锁分离（Read-Write Lock）
对读多写少场景，使用读写自旋锁（如rwlock），允许多个读线程并发访问，减少写线程阻塞时间
缓存行填充（Cache Line Padding）
将锁变量独占一个缓存行（如64字节对齐），避免与其他变量共享缓存行。例如Linux内核的spinlock_t结构体通过__attribute__((aligned(64)))强制对齐
分片锁（Sharded Lock）
将全局锁拆分为多个子锁，细化锁的粒度，通过哈希函数将资源映射到不同子锁，降低单个锁的争用率。例如，天翼云在高并发CDN场景中采用外层锁+内层锁的分级架构，通过哈希算法将80个Worker进程的竞争分散到多个外层锁，最终仅少数进程进入内层锁竞争
缓存行乒乓效应
缓存行乒乓效应（Cache Line Ping-Pong Effect）是多核系统中因多个处理器频繁读写同一缓存行导致的高性能损耗现象，其本质是缓存一致性协议（如MESI）的频繁触发。以下从原理、影响及优化策略展开分析： 共享缓存行的争用
当多个CPU核心同时访问同一缓存行内的数据时（即使数据不同），会触发缓存一致性协议（如MESI）的广播机制。例如：
假共享（False Sharing）：不同线程访问同一缓存行中的独立数据（如数组相邻元素），导致缓存行被频繁无效化
硬件机制的限制
缓存行粒度：缓存以固定大小（通常64字节）的缓存行为单位管理，无法区分同一缓存行内的不同数据 MESI协议开销：每次缓存行状态变更（如从Modified到Invalid）需跨核心同步，导致总线带宽和CPU周期浪费
二、性能影响
吞吐量下降
单核场景下操作耗时若为1单位，双核可能因乒乓效应增至2-3单位
例如，全局计数器在多核下的吞吐量可能随线程数增加而指数级下降
资源浪费
缓存带宽占用：缓存行频繁传递占用内存控制器带宽；
CPU空闲等待：核心因等待缓存行同步而无法执行有效指令
三、优化策略
将高频访问的变量独占一个缓存行，避免假共享。例如：