这里先给大家分享一个小故事&＃xff1a;
在我刚开始参加工作的那年&＃xff0c;公司安排我开发一款即时通讯软件(IM&＃xff0c;类似于 QQ 聊天软件)&＃xff0c;在这之前我心里也知道如果多线程操作一个整型值是要加锁的&＃xff0c;但是当时为了图代码简便&＃xff0c;而且在实际调试的时候&＃xff0c;没有加锁的代码也从来没出过问题。于是我就心存侥幸了&＃xff0c;觉得对整型值加锁真是多此一举。
我们的软件有类似于 QQ 这种单人聊天功能&＃xff0c;每个用户都有一个整型的 userid&＃xff0c;问题就出在这里。当时公司的老板和他妻子也使用这款软件&＃xff0c;问题来了&＃xff1a;有一天早上老板在这个软件上给他妻子发了一段亲密的话。问题来了&＃xff0c;由于多线程操作他妻子的 userid 没加锁&＃xff0c;最终变成了另外一个人的 userid&＃xff0c;而这个 userid 恰好是我的账户。于是老板发给他妻子的聊天内容就被发给我了。
我当时看到聊天内容很奇怪&＃xff0c;还回复了他一句&＃xff0c;并且还带上了我自己的姓名……事情的结果&＃xff0c;可想而知了&＃xff0c;老板非常尴尬也非常生气……从那以后&＃xff0c;老板看我的眼神都是怪怪的。我自知理亏&＃xff0c;再也不侥幸了&＃xff0c;凡是多线程读写整型变量都养成加锁的好习惯。
这是我曾经犯过的错误&＃xff0c;也就是所谓的线程安全问题。“年轻”时的我&＃xff0c;当时不明白为什么一个整型变量在多线程操作时存在安全问题&＃xff0c;进而引起业务上的错乱问题。
很多年以前的时候&＃xff0c;技术面试的时候面试官经常会问“程序什么时候需要开启新的线程”这样的问题&＃xff0c;那个时候多核 CPU 才刚开始普及&＃xff0c;很多人也是才开始逐渐接触多线程技术。而如今多核 CPU 和多线程编程技术已经是下里巴人的技术了。
因此“程序什么时候需要开启新的线程”这一类问题&＃xff0c;简单解释一下&＃xff0c;就是为了提高解决问题的效率&＃xff0c;毕竟大多数情况下&＃xff0c;多个 CPU 并行做一件事总比单个 CPU 做要快很多。然而&＃xff0c;
多线程程序虽然强大&＃xff0c;但也让原来的程序执行流程变得复杂和具有一定的不确定性&＃xff0c;比如带来资源的竞态问题&＃xff0c;初学者或许意识不到带来的后果&＃xff0c;往往不能够很好处理这个问题&＃xff0c;帮助学习多线程编程的初中级读者&＃xff0c;理清多线程程序的执行原理、脉络是我写专栏的创作初衷之一。由于各种库和运行环境对操作系统多线程接口的封装&＃xff0c;很多技术开发者做了很多年的开发&＃xff0c;仍然只是个界面或者仅知道调用库的“业务”程序员&＃xff0c;他们只能面向搜索引擎编程&＃xff0c;遇到稍微复杂一点的多线程逻辑就不知如何下手了。
本专栏将从操作系统原理的角度介绍多线程技术的方方面面&＃xff0c;从基础的知识到高级进阶&＃xff0c;它们是笔者这些年工作的经验总结和踩坑之后的教训。
本专栏的内容主要分为以下三大方面。
操作系统层面上关于多线程和多线程协作的接口原理
无论是哪种编程语言和库&＃xff0c;其最终都是要运行在操作系统上的&＃xff0c;应用程序本身的特性应该是决定采用何种编程工具的最主要因素&＃xff0c;但是无论你采用什么样的编程语言&＃xff0c;通过了解操作系统 API 从而深入理解操作系统的工作原理&＃xff0c;这本身就有很重要的意义。
操作系统是一个非常复杂的系统&＃xff0c;在 API 之上加一层编程语言并不能消除其复杂性&＃xff0c;最多不过是把复杂性隐藏起来而已。说不定什么时候&＃xff0c;复杂的那一面迟早会蹦出来拖你的后腿&＃xff0c;懂得系统 API 能让你可以更快地挣脱困境。
因此&＃xff0c;针对多线程编程&＃xff0c;本专栏将详细地介绍 Windows 和 Linux 操作系统层面上提供的各种多线程接口&＃xff0c;理解并熟悉它们的使用后&＃xff0c;读者在接触或者学习其他语言或者库提供的多线程功能时&＃xff0c;可以快速地上手和掌握。
以协程这一技术为例&＃xff0c;虽然协程是计算机操作系统原理之一&＃xff0c;但是我们所接触的大多数操作系统并没有从系统层面上支持协程这一技术。
而像 Golang 这一类语言是提供协程功能的&＃xff0c;那这一类语言是如何支持的&＃xff1f;如果你对操作系统的线程有着深入的了解&＃xff0c;你也不难想明白&＃xff1a;
线程是操作系统的内核对象&＃xff0c;当多线程编程时&＃xff0c;如果线程数过多&＃xff0c;就会导致频繁地上下文切换&＃xff0c;这些对性能是一种额外的损耗。
协程&＃xff0c;是在应用层模拟的线程&＃xff0c;它避免了上下文切换的额外损耗&＃xff0c;同时又兼顾了多线程的优点&＃xff0c;简化了高并发程序的复杂度。
再例如&＃xff0c;线程局部存储技术是我们常用的一项多线程技术&＃xff0c;它的存在让每个线程可以有自己私有存放数据的空间。那线程局部存储技术是如何实现的呢&＃xff1f;本专栏中会庖丁解牛地介绍线程局部存储是什么以及它的实现原理。
基于操作系统多线程理论衍生出来的一些扩展理论模型和应用
正因为存在多线程编程&＃xff0c;所以有了线程池模型&＃xff0c;据我了解&＃xff0c;“线程池”的实现和原理应该是多线程编程新手问的、聊的最多的一个技术点了。
本专栏会带领读者利用各种操作系统提供的线程同步对象来实现一个线程池&＃xff0c;进而引出生产者消费者理论模型&＃xff0c;再进一步升华&＃xff0c;引出所谓的消息中间件&＃xff0c;如 Kafka、RabbitMQ。
对于技术方案&＃xff0c;我们不推崇重复造轮子&＃xff0c;但是一定要具有重复造轮子的能力和了解轮子的制造原理。有了这项能力之后&＃xff0c;在使用一些开源的消息中间件时&＃xff0c;我们因为“知其然、知其所以然”才会把这些软件在项目中用得更好。
本专栏中会详细地介绍多线程操作整型变量非线程安全的原因以及解决方案。掌握了这些&＃xff0c;你在学习像 Java 语言时&＃xff0c;就明白了为什么 JDK 在操作一个整型变量时提供 AtomicInteger 这样的类了。
和多线程相关的&＃xff0c;一些实际开发中的技巧和经验
如果你是一名开发者&＃xff0c;那么曾经或许会为下面一些问题而头痛过&＃xff0c;这些问题或许你在面试时被面试官问到或者在实际开发中遇到过&＃xff1a;
诸如此类实际开发中经常遇到问题&＃xff0c;实在太多了&＃xff0c;这里就不一一列举了。本专栏在保持主干脉络介绍的同时&＃xff0c;也会穿插介绍一些与多线程相关的开发技巧和经验。
当然&＃xff0c;多线程问题本来就比较复杂&＃xff0c;尤其是本专栏同时介绍 Windows 和 Linux 两个操作系统平台的接口&＃xff0c;在实际编写程序时&＃xff0c;由于操作系统提供的 API 不一样&＃xff0c;为了跨平台&＃xff0c;我们不得不写许多跨平台代码。好在&＃xff0c;C&＃43;&＃43; 11/14 标准给 C&＃43;&＃43; 引入了大量的多线程类和库&＃xff0c;本专栏也会详尽地介绍它们的用法。
扫码查看《C/C&＃43;&＃43;多线程编程精髓》专栏详情▼
以下是专栏的主要内容导图&＃xff1a;
内容亮点&＃xff1a;你将获得&＃xff1a;由于操作系统调度线程时的不确定性&＃xff0c;同样的逻辑可能在不同机器、不同时刻有不同的行为表现&＃xff0c;也因此增加了排查和定位问题的难度。这是在学习和开发多线程程序时不得不面临的问题。
建议读者将专栏各个章节中的代码示例都实际在机器上运行一遍&＃xff0c;认真、准确地理解每一个多线程同步原语的适用场景和性能优缺点。只要透彻地理解了这些操作系统提供的基础多线程同步原语&＃xff0c;在面对它们的衍生物(如线程池、消息队列、协程技术等)时可以更快地学习和用好。
操作系统提供的 API 接口一般在相当长的时间内会保持不变的(至少保持向后兼容)&＃xff0c;一经学会&＃xff0c;终生受用。在新技术新思想层出不穷、令人应接不暇时&＃xff0c;掌握了操作系统层面的 API 和其设计思想原理&＃xff0c;可以以不变应万变。
最后&＃xff0c;多线程编程在现代软件开发中是如此的重要&＃xff0c;以至于熟练使用多线程编程是一名合格的后台开发人员的基本功&＃xff0c;它是如此的重要&＃xff0c;希望本专栏能帮助你掌握它&＃xff0c;愿它能让你彻底告别多线程编程烦恼。
。
京公网安备 11010802041100号