老板叫你别阻塞了
Java 多线程系列文章第 4 篇。
继续咱们的 Java 多线程系列文章,今天再讲讲概念,这篇应该是最后一篇基础概念,接下来就直接进入 Java 多线程主题了,在后面的文章里如果有概念需要单独拿出来讲时再补充概念篇。
这篇文章主要讲讲阻塞(Blocking)和非阻塞(Non-blocking)。
上班后必学第一技能
以前在学校做项目,基本上都是独立开发,每个人开发一个部分,以最小化沟通成本的方式划分工作量。到了职场,单纯的以最小化对接成本来安排工作是几乎不可能的,要考虑的因素变多了,各种跨小组、跨部门、甚至跨职场的工作,这就带来了沟通成本以及工作对接的各种阻塞问题。
新人刚入职场的时候,对一切都不熟悉,在做一些小组以外的对接工作时,就会遇到种种问题,特别现在充斥着各种分布式架构,以前开发 Web 后台的同学要会开发 JSP 页面,而现在前后端都分离了。设想一下这个场景。
小明是学习前端出身,刚开始步入职场,做的第一个需求就是登录和注册界面,需要对接一个写后台的同事小东,小东负责开发登录和注册的后台逻辑。小明开发了登录界面,准备和小东对接联调登录功能,这时小东回复说他刚好有生产 bug 在跟进,还没开发好,这时小明该怎么做?
有 2 种做法:
-
干等着小东开发好登录后台,再和他联调。
-
开发注册界面,开发过程中再时刻询问小东登录后台接口是否做完了,如果小东做完了,再去对接。
这 2 种做法的关键区别是什么呢?对于小东来说,没啥区别,他能做的就是尽量早点实现他的功能点。主要关注小明,第一种做法,小明做好了登录界面,接着则等待小东的登录后台接口,如果小东要开发一下午,那么小明就一下午啥事也不干,这种情况就是阻塞,小明的其他任务因为登录界面没对接联调,而一直阻塞着;第二种做法,小明得知小东登录后台接口还没实现,就着手先做注册界面的功能,然后每过一个小时跟小东确认一下登录后台接口开发是否开发完成,直到小东开发完登录后台接口,便开始对接联调,这种情况就是非阻塞,登录界面没对接联调完全不影响小明的开发进度,能联调的时候就联调,无法联调就完成手头上的其他任务。
可能有些同学初入职场会犯这类错误,做的功能依赖别人,因为别人还没做完,然后就采用第一种做法,一直干等着,直到对方完成后再继续工作。偶尔偷偷懒还行,如果一直是这样的工作状态,对初入职场的同学没有好处,而且这个被老板知道很不好。如果某一个需求点阻塞了,应该就先做手头上其他工作,如果手头上没其他工作,就跟老板反馈情况后领其他任务做,还要时刻去跟进阻塞的需求点的进度。
下面用流程图来描述这 2 个概念:
阻塞
非阻塞
看了上面的图,是不是更加理解阻塞与非阻塞了呢?
老板说了算
如果你是老板,或者说是小明的领导,你会让小明怎么做?第一种做法还是第二种做法呢?有支持第一种做法的,麻烦联系我,你们公司还招人么?
推荐阅读
后台回复『设计模式』可以获取《一故事一设计模式》电子书
觉得文章有用帮忙转发&点赞,多谢朋友们!
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
「2019 JSConf.Asia - Kas Perch」WebAssembly - JS 的未来和 Web 多语言开发
特别说明 这是一个由 simviso 团队对 JSConf.Asia 中关于 WebAssembly 相关话题进行翻译的文档,内容并非直译,其中有一些是译者自身的思考。分享者是 Kas Perch,Cloudflare 的一名开发人员。 现在,让我们一起来了解下什么是 WebAssembly。 视频地址:WebAssembly - JS 的未来和 Web 多语言开发 视频翻译版权归 simviso 所有 本次参与翻译人员 前端公众号: 一、前言 大家好,太棒了。就像他们所说,如果我们搞定了 WebAssembly 技术,那么就搞定了 JS 的未来和 Web 多语言开发。 正如介绍所言,我叫 Kas Perch,现在是 Cloudflare 公司的一名 Avocado 开发人员。同时,我也很痴迷于机器人编程,并且写过相关书籍。 我已经写了两本使用 JS 给机器人编程的书。我周末也会在 twitch 上直播一些硬件和软件相关的东西。 我养了两只猫,它们是我的最爱。左边的猫叫 Ace,右边的叫 Aria。它们现在对我很生气,因为我已经离开它们三个星期了。 我可能再过一个星期才回去,它们是真的...
- 下一篇
一次难得的分库分表实践
背景 前不久发过两篇关于分表的文章: 一次分表踩坑实践的探讨 分表后需要注意的二三事 从标题可以看得出来,当时我们只做了分表;还是由于业务发展,截止到现在也做了分库,目前看来都还比较顺利,所以借着脑子还记得清楚来一次复盘。 <!--more--> 先来回顾下整个分库分表的流程如下: 整个过程也很好理解,基本符合大部分公司的一个发展方向。 很少会有业务一开始就会设计为分库分表,虽说这样会减少后续的坑,但部分公司刚开始都是以业务为主。 直到业务发展到单表无法支撑时,自然而然会考虑分表甚至分库的事情。 于是本篇会作一次总结,之前提过的内容可能会再重复一次。 分表 首先讨论下什么样的情况下适合分表? 根据我的经验来看,当某张表的数据量已经达到千万甚至上亿,同时日增数据量在 2% 以上。 当然这些数字并不是绝对的,最重要的还是对这张表的写入和查询都已经影响到正常业务执行,比如查询速度明显下降,数据库整体 IO 居高不下等。 而谈到分表时我们着重讨论的还是水平分表; 也就是将一张大表数据通过某种路由算法将数据尽可能的均匀分配到 N 张小表中。 Range 而分表策略也有好几种,分别适用...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7