Linux生产者消费者模型详解：从互斥锁到信号量的并发实践

1. 先把模型讲透三个角色、两个约束、一个缓冲区1.1 从烧水房讲起两个节奏不同的人怎么配合我去年排查一个线上问题背景是这样的某个业务模块把用户操作日志写进一个内存队列再由一个后台线程批量落盘。业务高峰期一过日志队列里积压了几万条数据消费者线程吭哧吭哧跑了几分钟才消化完。当时我盯着top里那个线程的CPU占用脑子里蹦出来的就是大学操作系统课上的那个经典名词生产者消费者模型。这个模型听起来像理论题实际上在Linux后端开发里天天出现——凡是两个线程节奏不一致、中间需要一个缓冲地带的地方都是它的主场。先用一个最朴素的场景理解它。一个烧水房烧水师傅负责烧水同事负责接水中间放一个大保温桶。师傅烧好一壶水就倒进桶里同事来了就从桶里接水。问题来了如果桶满了师傅还继续倒水会溢出来如果桶空了同事还干等着那就是浪费时间。于是立两条规矩桶满师傅停下等桶空同事等着等。这个保温桶就是缓冲区师傅是生产者同事是消费者。Linux上的生产者消费者模型跟烧水房没有任何本质区别只是把桶换成了环形队列、链表、管道或者信号量把人换成了pthread线程或进程。模型要解决的永远是同一件事两个速度不完全匹配的实体之间如何安全地传递数据既不溢出也不空等。为什么要专门把这两个角色区分开因为现实中的生产者和消费者节奏天然不同。生产者可能突然高频涌入消费者受磁盘IO、网络、锁竞争影响时快时慢。如果没有缓冲区硬把它们粘在一起快的那个就会被慢的那个直接拖死。有了缓冲区两边各干各的偶发波动全部被缓冲掉。1.2 缓冲区不只是临时停一下它带来三层价值第一层价值是削峰。数据库瞬间来了几千条写请求如果每条都让业务线程自己刷盘磁盘很快会被打瘫。生产者在内存队列里快速完成写入就返回消费者按自己能承受的速率慢慢落盘瞬时高峰被摊平了系统不会直接崩溃。第二层价值是解耦。生产者和消费者不需要知道对方的实现细节。生产者只关心队列还有没有空位有就放没有就等。消费者只关心队列有没有数据有就拿没有就等。两边唯一共同认识的东西就是缓冲区以及缓冲区上的约束规则。这跟流水线一个道理你只负责自己这道工序前一道工序用谁做的、做得快慢都跟你没关系。第三层价值是流量控制工程上更喜欢把它叫作背压。缓冲区一旦有界生产者就会被人为压住队列满了它必须等待消费者腾出位置。这个满了就等的机制天然就是一层节流阀。如果缓冲区做成无界的生产者就能无限塞入最终会把内存吃光把整个进程带崩。所以我做设计时只要没有特殊理由一律用有界队列。引入缓冲区也带来四个必须回答的问题缓冲区边界是多少生产者是一个还是多个消费者消费失败是重试还是丢弃生产结束后怎么让正在等待的消费者优雅退出这四个问题后面两章的代码里会全部碰到而且每一个都藏着坑。2. 互斥锁 条件变量Linux下最顺手的第一版实现2.1 为什么是pthread_mutex和pthread_condLinux线程库就是POSIX线程也就是pthread。做生产者消费者模型最经典的组合是pthread_mutex_t加pthread_cond_t。互斥锁负责互斥条件变量负责等待与唤醒两者必须配合使用。条件变量本身没有锁的能力它只提供一个睡觉和叫醒的机制。为什么必须挂在互斥锁上因为判断队列状态和修改队列状态是两个操作如果不在同一个锁原子区内就会产生竞态窗口。举个例子消费者检查count发现是0正打算睡觉结果刚检查完、还没进wait生产者插入了一条数据并发送了signal。消费者错过这个signal继续睡下去这条数据可能就没人消费了。这类检查条件和睡眠等待必须打包成一个原子动作而pthread_cond_wait恰好完成了这件事它后面就是释放锁、睡觉、被唤醒后重新抢锁整个过程对调用者来说看起来像一次原子操作。还有人会想用volatile加自旋锁行不行比如while (count CAPACITY) {}空转。行倒是行但坏处很明显空转期间CPU被吃到100%多核机器上整个核都在空烧。而且volatile解决不了编译器和CPU对指令重排的问题数据可见性没有保证。pthread互斥锁的实现自带内存屏障释放锁之前写的内容对抢到锁的线程一定可见这才是它隐藏的价值。2.2 一版能直接跑的完整代码我写的这一版用环形数组做有界缓冲区容量16。生产者总共生产100个整数消费者消费完100个之后自动退出。代码可以直接编译跑#include stdio.h #include stdlib.h #include unistd.h #include pthread.h #define CAPACITY 16 #define TOTAL 100 typedef struct { int buf[CAPACITY]; int head; int tail; int count; int done; pthread_mutex_t mtx; pthread_cond_t not_full; pthread_cond_t not_empty; } Queue; static void queue_init(Queue *q) { q-head q-tail q-count q-done 0; pthread_mutex_init(q-mtx, NULL); pthread_cond_init(q-not_full, NULL); pthread_cond_init(q-not_empty, NULL); } static void queue_push(Queue *q, int item) { pthread_mutex_lock(q-mtx); while (q-count CAPACITY) { pthread_cond_wait(q-not_full, q-mtx); } q-buf[q-tail] item; q-tail (q-tail 1) % CAPACITY; q-count; pthread_cond_signal(q-not_empty); pthread_mutex_unlock(q-mtx); } static int queue_pop(Queue *q, int *item) { pthread_mutex_lock(q-mtx); while (q-count 0) { if (q-done) { pthread_mutex_unlock(q-mtx); return -1; } pthread_cond_wait(q-not_empty, q-mtx); } *item q-buf[q-head]; q-head (q-head 1) % CAPACITY; q-count--; pthread_cond_signal(q-not_full); pthread_mutex_unlock(q-mtx); return 0; } static void *producer(void *arg) { Queue *q (Queue *)arg; for (int i 0; i TOTAL; i) { queue_push(q, i); usleep(rand() % 100000); } pthread_mutex_lock(q-mtx); q-done 1; pthread_cond_broadcast(q-not_empty); pthread_mutex_unlock(q-mtx); return NULL; } static void *consumer(void *arg) { Queue *q (Queue *)arg; int item; while (queue_pop(q, item) 0) { printf(consume %d\n, item); usleep(rand() % 200000); } return NULL; } int main(void) { Queue q; pthread_t p, c; queue_init(q); pthread_create(p, NULL, producer, q); pthread_create(c, NULL, consumer, q); pthread_join(p, NULL); pthread_join(c, NULL); printf(all done\n); return 0; }编译命令gcc -g -Wall producer_consumer_mutex.c -o pc_mutex -lpthread注意一定要加-lpthread这是Linux下链接pthread库的标准写法。在比较新的glibc版本里也可以写成-pthread它同时影响编译和链接。2.3 逐段拆解为什么这些细节不能少先看queue_push里的while循环。很多教科书为了简化会写if但工程上必须用while。原因是条件变量存在虚假唤醒线程被唤醒后队列的状态不一定真的满足条件。你被signal唤醒但另一个消费者可能抢先一步把唯一的数据取走了。用if判断的话你醒来后会直接去读一个空队列。用while重新判断一次不满足条件就继续睡这是唯一正确的写法。再看pthread_cond_wait为什么要把互斥锁传进去。wait的底层动作是将当前线程放入条件变量等待队列、释放互斥锁、挂起。被唤醒后它会重新竞争互斥锁抢到锁之后才从wait返回。这样检查条件和睡眠才能被原子地缝合在一起。如果先手动释放锁再去wait检查和释放之间就出了缝隙生产者照样会插入数据、发signal然后这个signal就被丢了。消费者返回-1的时机也要讲究。我把done的判断放在while循环里面、wait之前。这样设计的目的消费者把队列里的数据清空后发现done已经置位就直接退出不会再去等一个永远等不到的not_empty信号。如果先wait再判断done就有可能在生产者广播唤醒前一直睡下去逻辑上也能跑通但效率差了。producer结束时为什么用broadcast而不是signal单消费者场景signal就够但多消费者场景会出问题如果有两个消费者都在not_empty上睡觉signal只会唤醒其中一个。如果它醒来后发现队列又被另一个消费者清空了会重新睡回去而另一个消费者可能压根没被唤醒从此没人处理not_empty队列。broadcast把所有等待者都叫醒让它们各自重新检查条件这就安全了。2.4 多个生产者和多个消费者改动其实很小把上面的代码改成多生产者多消费者核心改动只有两点一是队列的count、head、tail都必须继续在锁内更新这一点原来的代码已经保证了二是唤醒尽量用broadcast降低唤醒了一个不满足条件的线程、真正的目标没被唤醒的概率。head和tail的分工有个容易忽略的点生产者只碰tail消费者只碰head不要交叉混淆。环形队列里消费者绝不能改tail生产者绝不能改head。锁保证修改互斥环形数组的下标逻辑保证空间复用这两者配合才不会出现数据互相覆盖。这里有个进阶信息如果是严格的单生产者单消费者其实可以不抢互斥锁head和tail各自只有一个线程在操作配合内存屏障就能安全读写。Linux内核里的kfifo以及一些高性能网络库就是这么干的。但这是优化级的玩法普通应用老老实实加锁别为了省那微秒级的开销引入难以调试的并发问题。正确性优先性能靠后。3. 换一把兵器用信号量实现同一个模型3.1 信号量的语义一个自带状态的计数器条件变量本身不携带任何状态它只是醒来吧这样一个信号必须配合共享变量和互斥锁才能判断对错。信号量不同它自己就是一个计数器初值、增减、等待都由内核帮你维护。理解信号量有两个经典操作sem_wait把值减一如果结果小于0调用者阻塞sem_post把值加一如果有阻塞的线程唤醒其中一个。对一个初值为10的信号量连续调用10次sem_wait还能正常运行第11次开始阻塞。你可以把它想成一个令牌箱里面有10个令牌每次wait就拿走一个每次post就放回一个箱子空了就只能等在旁边。拿信号量做生产者消费者模型设计思路非常清晰一个信号量empty记录缓冲区还剩多少个空位初值是缓冲区容量16一个信号量full记录缓冲区里有多少条数据初值是0。生产者要放数据必须先sem_wait(empty)表示占一个空位生产完sem_post(full)表示多了一条数据。消费者要取数据先sem_wait(full)表示拿走一条数据取完sem_post(empty)表示释放一个空位。两个信号量各自管理一种数量一拍即合。3.2 完整代码两个信号量加一把互斥锁#include stdio.h #include stdlib.h #include unistd.h #include pthread.h #include semaphore.h #define CAPACITY 16 #define TOTAL 100 sem_t empty; sem_t full; pthread_mutex_t mtx; int buf[CAPACITY]; int head 0; int tail 0; static void *producer(void *arg) { for (int i 0; i TOTAL; i) { sem_wait(empty); pthread_mutex_lock(mtx); buf[tail] i; tail (tail 1) % CAPACITY; pthread_mutex_unlock(mtx); sem_post(full); usleep(rand() % 100000); } return NULL; } static void *consumer(void *arg) { for (int i 0; i TOTAL; i) { sem_wait(full); pthread_mutex_lock(mtx); int item buf[head]; head (head 1) % CAPACITY; pthread_mutex_unlock(mtx); sem_post(empty); printf(consume %d\n, item); usleep(rand() % 200000); } return NULL; } int main(void) { pthread_t p, c; sem_init(empty, 0, CAPACITY); sem_init(full, 0, 0); pthread_mutex_init(mtx, NULL); pthread_create(p, NULL, producer, NULL); pthread_create(c, NULL, consumer, NULL); pthread_join(p, NULL); pthread_join(c, NULL); sem_destroy(empty); sem_destroy(full); pthread_mutex_destroy(mtx); printf(all done\n); return 0; }编译命令和第一版一样gcc -g -Wall producer_consumer_sem.c -o pc_sem -lpthread3.3 信号量版本背后的两个关键洞察先回答一个肯定会有人问的问题head和tail的修改为什么还需要再加一把互斥锁信号量只保证还有一个空位和还有一条数据它不保证对数组下标的读写是原子的。两个生产者几乎同时拿到空位如果都用tail变量tail这个操作不是原子的就会写重。所以槽位的计数交给信号量而下标和数组内容的修改交给互斥锁各管一摊。如果严格限定单生产者单消费者这把锁其实可以去掉head只有消费者写、tail只有生产者写配合信号量语义已经安全——我加锁是为了让示例对多生产者多消费者扩展友好实际按这种写法直接加线程数也不会崩。第二个洞察是退出机制。信号量版本里消费者没有done标志也不需要。生产者每生产一个数据就sem_post(full)一次消费者sem_wait(full)成功一次就消费一个。生产者生产100个full的最终值会把消费者的100次wait全部满足消费者循环100次后自然退出。这个用计数器天然记录生产数量的设计比条件变量版本里的手动done标志干净得多。两个版本各有优势我做了个对比表对比项互斥锁 条件变量信号量状态载体共享变量 条件变量信号量计数器锁的需求必须wait内部自动释放需要锁保护下标计数交给信号量多条件判断灵活支持not_full和not_empty两个独立条件用多个信号量模拟多条件退出逻辑需要手动维护done标志靠full计数自然退出语义清晰度需要理解wait/notify的微妙之处更接近直觉计数器说话调试难度唤醒丢失、虚假唤醒容易踩语义清晰问题多半出在初始化值上4. 这些坑我全踩过你也绕开走四条并发问题的完整排查链路4.1 虚假唤醒从一行if开始的线上事故先说一个真实事故。有一次线上日志服务偶发地打印出空内容不是稳定复现是那种隔几小时冒一次的邪门问题。代码里消费者线程用的是if (count 0) pthread_cond_wait(...)取数据前只判断了一次。日志打到一半消费者醒了队列恰好是空的它直接读了空指针。这行if写法几乎出现在每一本并发编程教材的简化示例里但它就是不安全。排查链路是这样的先看日志出现的时间规律发现每隔一段时间必现且和业务高峰期错开用gdb attach到消费者线程在取数据处打断点观察到线程确实从wait返回但count仍为0再看代码for循环改if原因就清楚了。修复就是把if换成while让线程醒来后重新检查条件。这里说明一下虚假唤醒不是说Linux实现有bug而是POSIX标准允许pthread_cond_wait在没有signal/broadcast的情况下返回也可能因为信号中断返回。即便你的代码遵守所有规范这种情况照样可能发生。所以while是底线不是可选项。4.2 唤醒丢失signal叫醒的不是对的那个人多消费者场景下还有一个隐蔽问题叫唤醒丢失。假设缓冲区里只有一条数据两个消费者都在not_empty上等。生产者push后执行signal只唤醒其中一个消费者A。A被唤醒后抢到锁发现队列里有数据取走然后继续循环。等A再回到wait时另一个消费者B还沉睡在not_empty队列里——它被signal漏掉了。如果这种事情反复发生可能会造成某条消息被延迟很久才被处理甚至在某些错误实现里永远没人处理。避免唤醒丢失的方法不确定有多少消费者在等时尽量用broadcast。broadcast把等待队列里的所有线程都叫醒让它们自己重新检查条件不满足条件的会继续睡回去。代价是被叫醒的线程都去抢同一把锁增加一点锁竞争但换来正确性。对大多数业务系统来说这比省那点竞争开销重要得多。排查时可以用strace看futex相关的唤醒调用。strace -f -e tracefutex -p pid能看到FUTEX_WAIT和FUTEX_WAKE的调用次数。如果FUTEX_WAKE的次数明显少于生产数据条数那就说明有唤醒被漏掉的嫌疑。4.3 死锁的两种典型姿势死锁是并发程序最让人头疼的问题。我见过的生产者消费者模型死锁基本逃不出两种姿势。第一种是加锁顺序问题。线程A持有队列锁然后去sem_wait(full)线程B持有另一把锁然后又来抢队列锁。如果A等full、B等队列锁两边互相等谁也动不了。规避方法很简单约定全局加锁顺序要么先信号量后互斥锁要么反过来所有线程统一。比如我上面的信号量版本里消费者先sem_wait(full)再pthread_mutex_lock(mtx)顺序统一就不会出现这种交叉等待。第二种是忘记释放锁。queue_push里面某条分支被return击穿锁没释放。这个问题在代码review时最容易漏。我的习惯是加锁函数尽量保持单一出口或者用pthread_mutex_unlock在return前显式释放。如果实在担心可以用gdb的thread apply all bt看线程栈卡在__lll_lock_wait的线程就是在等锁卡在pthread_cond_wait的就是在等条件变量。把两个线程的栈放一起看谁拿着哪把锁、谁在等哪把锁一目了然。4.4 内存可见性volatile不是并发银弹初学并发时我也犯过这个错觉得count变量加个volatile多线程就能安全读了。实际测试有时候能跑通有时候莫名其妙读到过期数据。原因是volatile只告诉编译器这个变量每次都从内存读但它不阻止CPU在内存模型层面的重排也不提供任何原子性保证。一个线程count另一个线程读count看到的很可能是旧值。pthread_mutex_lock/unlock的意义远不止互斥它自带内存屏障释放锁之前写的内容对之后抢到锁的线程是可见的。我的条件变量版本里count的读写、队列数据的读写全在锁内完成这就是为什么它能保证消费者看到的永远是最新的数据。这也是我强烈建议宁可加锁也不要手动搞无锁优化的原因——你以为省了时间实际上把正确性交给了CPU架构的运气。检测数据竞争有一个很好用的工具helgrind。编译时加-g然后valgrind --toolhelgrind ./pc_mutex如果代码里有未加保护的数据访问它会把冲突的读写地址、线程栈全部打出来。我第一次跑的时候它抓出了一个我没意识到的数据竞争那个位置我根本没加锁。这种工具值得在每个并发Demo上都过一遍。5. 用Linux常用命令把生产者和消费者看清楚5.1 ps和top先找到你的线程写并发程序第一步永远是先确定线程真实存在。Linux下用ps就能看线程ps -eLf | grep pc_mutex输出里每个线程一行LWP列就是线程ID。pc_mutex程序跑起来后你会看到两个LWP对应生产者线程和消费者线程还有主线程。如果只有一行说明你代码里的线程创建可能失败了或者线程已经退出了。top也能看需要指定线程模式top -H -p pid-H打开线程视图后你能看到每个线程的CPU占用。如果生产者线程CPU一直100%说明它在空转等待锁或者自旋如果消费者线程长时间睡眠CPU占用接近0说明队列经常是空的消费者在等数据。这些特征都能帮你判断模型跑得是否健康。5.2 strace深入futex的世界Linux下互斥锁和条件变量的底层实现都依赖futex系统调用。用strace能看到线程在什么时候真正睡下去、什么时候被唤醒strace -f -e tracefutex -p pid输出里会出现FUTEX_WAIT和FUTEX_WAKE。FUTEX_WAIT表示线程进入等待队列FUTEX_WAKE表示有人唤醒了等待者。如果你看到某个线程长时间停留在FUTEX_WAIT_PRIVATE说明它正在等锁或者等条件变量。再对照另一个线程就能画出它们之间的同步关系。这条命令在排查为什么消费者不工作了这类问题时特别管用如果消费者线程一直在FUTEX_WAIT但生产者已经生产了很多条数据那说明唤醒丢失或者done标志逻辑有误。5.3 ipcs和gdb检查信号量我前面用的POSIX无名信号量在进程内存里ipcs看不到。如果你用System V信号量semget接口可以这样查看ipcs -s输出里会列出当前系统上的所有信号量集合包括key、权限、当前值。当前值就是信号量计数器的实时状态。对于POSIX无名信号量想看当前值可以用sem_getvalue或者干脆在gdb里直接查看gdb -p pid (gdb) p full (gdb) p emptygdb能直接读出sem_t结构内部的值虽然打印出来的结构体比较乱但count字段能看出来。我在调试信号量版本时经常这么干如果empty的值一直卡在0说明缓冲区满了生产者被压住了如果full的值一直卡在0说明队列空了消费者在干等。5.4 helgrind和ThreadSanitizer自动化找数据竞争检查线程并发问题最省心的方式还是工具。前面提到的helgrind是valgrind家族的一员专门做数据竞争检测。它的缺点是慢Demo没问题生产程序跑不动。另一个选择是GCC自带的ThreadSanitizergcc -g -fsanitizethread producer_consumer_mutex.c -o pc_tsan -lpthread ./pc_tsanTSan在运行时检测报告格式清晰直接指出哪一行发生了数据竞争、两个线程分别在哪。我第一次在自写的无锁队列上跑TSan它报了一堆问题当时我还不服气后来逐个分析发现是我对内存序的理解错了。从此我对不用锁我也能写对这种想法保持敬畏。6. 从Demo到真系统模型在日志、连接池、Docker容器里的真实样子6.1 异步日志最典型的生产者消费者场景Linux上的日志系统几乎都是这个模型。业务线程调用log.info()时实际是往一个内存队列里写入日志消息——业务线程是生产者。队列后面有一个独立的日志线程把队列里的消息批量格式化、写入磁盘——它是消费者。这里最需要决策的就是队列满时怎么办。常见策略有三种阻塞、丢弃、覆盖最旧。阻塞最安全但会拖慢业务丢弃在日志场景下能接受但不是所有日志都行覆盖最旧适合实时性强的场景。spdlog这类成熟的日志库把这些策略都做成了选项。我自己的经验是日志这种场景可以适当放宽队列容量或者用丢最旧策略保证系统不崩比每条日志都完整更重要。当然审计类日志例外那类数据必须可靠落盘阻塞反而是合理选择。6.2 数据库连接池消费和生产的角色会互换连接池是另一个经典案例。业务线程去连接池申请连接时它是消费者连接池本身有专门的后台维护线程负责按需创建新连接、回收空闲连接、清理过期连接这些维护线程是生产者。这里有个跟普通模型不太一样的点生产者和消费者有时会互调。连接池里的初始连接数太少业务流量一起来消费者们全在等连接。此时维护线程赶紧生产新连接但生产一个TCP连接可能需要几十到几百毫秒消费者等不起。所以连接池设计必须内置两个参数最小空闲连接数和最大连接数同时提前预热。这其实就是给生产者设计了策略预先多生产一点而不是等消费方催。你看生产者消费者模型并不只是两个线程之间传数据它同样能解释资源池这类场景关键是把资源的生命周期管理看成生产行为把资源的获取归还看成消费行为。6.3 Docker容器里的生产者消费者从进程内到跨容器近些年在Linux上部署服务绕不开容器化。装好Docker以后最典型的做法是docker-compose拉起一个生产者服务和一个消费者服务中间放一个队列容器比如Redis或RabbitMQ。这仍然是生产者消费者模型只是角色从线程变成了进程缓冲区从内存队列变成了网络上的消息服务。我第一个跑通的Docker版生产者消费者Demo是这样的生产者服务负责接收HTTP请求把任务数据写入Redis的List数据结构消费者服务从List的另一端用BLPOP阻塞读取处理任务。数据在容器网络里走了一遭模型的内核没变生产者推消费者拉中间有缓冲满了就等待。容器对CPU、内存做了隔离反而让并发问题更容易复现——因为调度更加捉摸不定了虚假唤醒、超时重试都要处理得比裸机更小心。用Docker部署这类程序还有一个好处观察工具是现成的。docker stats看容器CPU和内存docker logs看业务日志docker exec进容器里跑ps和strace排查链路和在物理机上几乎一模一样。6.4 什么时候才需要上无锁队列看完整篇文章你可能有个疑问既然带锁能解决问题为什么还有人在讨论无锁队列无锁队列适合的是极高频场景比如交易系统的行情推送、网络网关的数据包转发。这些场景里锁竞争占了很大比例单线程处理不过来了才值得引入无锁设计。无锁队列的代价很大正确性难以验证ABA问题、内存管理、内存序的细微差别每个都够排查几天。所以我的建议是分三步走第一步先实现一个带锁版本保证逻辑正确第二步用性能测试工具压一压看锁竞争到底占了多少CPU第三步如果确实成为瓶颈优先选成熟的lockfree库而不是自己手写。多数业务系统走到第二步就发现瓶颈不在锁上真正要优化的是IO和网络。别为了炫技把自己架在火山口上。从线程间的内存队列到进程间的消息队列再到Docker容器里的队列服务生产者消费者模型一路从底层往上走但核心约束没变过缓冲区有界生产者等空位消费者等数据。把这个内核吃透了Linux并发编程的很多问题都只是它的变体。最后留一个实际操作的小建议与其背各种理论不如下载一个Linux镜像装个虚拟机把文中的两段代码敲进去跑一遍再改成多生产者多消费者用strace和gdb亲眼看看线程等待的模样。无论你用的是Ubuntu、CentOS还是国内团队基于Linux内核构建的发行版这套pthread接口都是通用的学会了在哪都能用。