threadpool

前几天一位朋友去面试，面试官问了他同步，异步，多线程之间是什么关系，异步比同步高效在哪？多线程比单线程高效在哪？由于回答的不好，让我帮他捋一下，其实回答这个问题不难，难就难在只对别人说理论，而没有现杀的例子。 一：异步 1. 到底解放了谁？ <1> 从基础的同步说起 要说解放了谁，一定得有几个参与者，举个例子：当你的主线程读取一个应用程序之外的资源时，它有可能是一个文件，又有可能是一个外部服务，当用同步方式读取外部服务时，首先主线程会从用户模式进入到内核模式，在内核模式中windows会将你的请求数据交给对应的网络驱动程序，继后会让这个线程进入休眠状态，当网络驱动程序和外部服务一阵痉挛之后，网络驱动程序会将获取到的结果交给当初休眠的线程，windows唤醒休眠线程继而执行后续的C#代码，画个简图理解一下，不一定全对。 这里就存在着一个非常大的问题，步骤4-步骤7之间，你的主线程一直都是休眠状态，比如在GUI编程中，有一个重要的原则就是解放你的UI线程（主线程），所以解决这个问题就迫在眉睫。 <2> 异步方式下的处理方案 说到这里，大家应该知道了异步方式就是为了解放主线程，又可以叫调用线程，没错，接下来看一下同样的场景在异步中如何处理的。 从图中可以看到，步骤三中将thread数据交给网络驱动程序之后，该thread就直接返回不管了，当后续网络驱动程序获取数据后

| 好看请赞，养成习惯 你有一个思想，我有一个思想，我们交换后，一个人就有两个思想 If you can NOT explain it simply, you do NOT understand it well enough 现陆续将Demo代码和技术文章整理在一起 Github实践精选 ，方便大家阅读查看，本文同样收录在此，觉得不错，还请Star 最近在陆续写 Java 并发编程系列 ，好多朋私信问我的不是并发内容本身，而是我的 IDEA 主题配置。我就姑且认为好的主题配置可以写出更好的并发程序吧 即便这种可能性只有万分之一，我也要把我的 IDEA 相关值得配置的内容/插件和大家分享出来（其实我还是很乐意将我的一些配置分享出来帮助大家更加高效的coding）） 先来一张我的 IDE 截图，有你看中的地方吗？ 插件篇 好用的插件总是让人： 神清气爽，精神抖擞 ，丰神异彩，炯炯有神，神采奕奕，气贯长虹 ，英姿飒爽，精神焕发 下面所有插件都可以按照文中标注的名称在 IDEA 插件市场中直接搜索并安装 Material Theme UI Material Theme UI 在主题下载量排行榜中高居第一。安装主题后（在页面底部就会有进入主题的快捷入口），选择自己喜欢的主题进行微调就可以啦，如果懒得做配置，按照下图勾选相应设置就和我的一样了： Rainbow Brackets 翻译过来叫

pika的线程模型有官方的wiki介绍https://github.com/Qihoo360/pika/wiki/pika-%E7%BA%BF%E7%A8%8B%E6%A8%A1%E5%9E%8B，这里主要介绍了pika都有哪些线程，这些线程用来干嘛。本篇文章主要涉及监听线程DispatchThread、IO工作线程WorkerThread和工作线程池ThreadPool，结合代码介绍里面实现的一些细节。 1.监听线程DispatchThread 在创建PikaServer的时候，会构造一个PikaDispatchThread，这个PikaDispatchThread，实际上是用了pink网络库的DispatchThread::DispatchThread DispatchThread构造函数里面会初始化好若干个WorkerThread DispatchThread继承自ServerThread，ServerThread继承了Thread，线程启动时实际上运行的是子类的ThreadMain方法，继承了Thread类的子类需要有自己的ThreadMain，监听线程start的时候，入口是ServerThread::ThreadMain()。线程启动会先ServerThread::InitHandle()，绑定和监听端口，下面看看ServerThread::ThreadMain(

作者：午夜逛街的黛玛 链接： zhuanlan.zhihu.com/p/58466826 前言 大家都知道寒冬来了，我们要储备足够的粮食才能过冬。我经历了国企、外企、创业和 BAT，通过自己的亲身体会告诉大家，如果你想要在国内长期发展，请尽早进入大厂。我简单的把自己的体会归纳为如下几点，希望对金三银四准备跳槽的你有一些帮助。 公平 我们大家都知道一线城市比二线城市更公平，更开放。大厂也是一样的，大厂有更多的包容，即便是最近的寒冬零星的大厂分别裁员，整体大厂的环境还是不错的。 如果是小公司会有更多的参差不齐，各种裙带关系，各种克扣军饷。只要能 8k 招聘你绝对不会给你 9k，只要能通过避税节省开销绝对不会给你多上一分公积金。如果业务不景气马上就会开掉你，如果业务不明朗在试水，会考虑多招聘几个 70% 试用期的人做完就开除来减少成本。当然不是所有的小公司都这样，但是他确实是一个真实存在的现象。 大公司就截然不同，即便是某团要裁员他也会优先内部竞岗，即便是某滴裁员力度很大，但是也觉得会留住自己的主业务和裁员补偿，即便是某东高喝 10% 的裁员，也是按照优胜劣汰来评估。 这就给了你更多的选择，更多的公平。 成长 有人说我在某某公司独立负责 3 个 App 的开发和运维工作，已经是技术负责人了。那么这才是非常严重的问题，因为你现在解决问题基本靠自己了，没有产入。遇到问题你的解决方案便是最优的

前几天写了个java爬虫爬花瓣网，但是事后总感觉不够舒服，终于在今天下午写了个python爬虫(爬微博图片滴),写完之后就感觉舒服了，果然爬虫就应该用python来写,哈哈(这里开个玩笑，非引战言论)。话不多说进入正题。 1.分析页面 我之前去网上搜了一圈爬微博的爬虫大都是采用模拟登陆的方式爬取，我这里并没有采用那种方式，直接是通过模拟请求得到数据的。如下(爬取的微博: https://m.weibo.cn/profile/1792328230 ) 这个页面是该博主的个人简介页面，直接拉到底，会有一个查看所有微博，点击它会跳转到该博主的所有微博页面 这里打开开发者工具查看网络请求，找到这个数据接口https://m.weibo.cn/api/container/getIndex?containerid=2304131792328230_-_WEIBO_SECOND_PROFILE_WEIBO，你会发现本页面所有内容都在该请求返回的json数据包中。 接着往下滑页面继续观察该请求窗口，就会发现这个接口的参数的规律。发现规律后就是老一套的模拟ajax加载获取多页数据，然后爬取目标内容。该数据接口参数如下: https://m.weibo.cn/api/container/getIndex?containerid=?&page= ? 其中参数id是指定该用户，page就是页数

前言 我在写代码的时候（.net core）有时候会碰到void方法里，调用async方法并且Wait，而且我还看到别人这么写了。而且我这么写的时候，编译器没有提示任何警告。但是看了dudu的文章: 一码阻塞，万码等待：ASP.NET Core 同步方法调用异步方法“死锁”的真相 了解了，这样写是有问题的。但是为什么会有问题呢？我又阅读了dudu文章里提到的一篇博文： .NET Threadpool starvation, and how queuing makes it worse 加上自己亲手实验，写下自己的理解，算是对dudu博文的一个补充和丰富吧。 同步方法里调用异步方法 同步方法里调用异步方法，一种是wait() 一种是不wait() void fun() { funAsync.Wait(); funAsync(); } 这两种场景都没有编译错误。 首先我们来看一下，在 void里调用 async 方法，并且要 等待 async的结果出来之后，才能进行后续的操作。 using System; using System.Threading; using System.Threading.Tasks; namespace ConsoleTool2 { class Program { static void Main(string[] args) { Producer(); }

现象 观察 ThreadPoolExecutor的submit代码： def _adjust_thread_count(self): # When the executor gets lost, the weakref callback will wake up # the worker threads. def weakref_cb(_, q=self._work_queue): q.put(None) # TODO(bquinlan): Should avoid creating new threads if there are more # idle threads than items in the work queue. if len(self._threads) < self._max_workers: t = threading.Thread(target=_worker, args=(weakref.ref(self, weakref_cb), self._work_queue)) t.daemon = True #确实是守护线程 t.start() self._threads.add(t) _threads_queues[t] = self._work_queue 在线程池里面启动的线程确实都是守护线程，但是主线程退出后，进程并没有退出，而是还在等子线程结束