老板叫你别阻塞了
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。它们现在对我很生气,因为我已经离开它们三个星期了。 我可能再过一个星期才回去,它们是真的...
-
下一篇
四要素落地持续交付
本文通过持续集成、自动化测试、流水线以及自动化部署几个要素介绍宜信的持续交付平台及实践。 一、什么是持续交付 持续交付(Continuous delivery,缩写为 CD),是一种软件工程方法,让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的编译、测试与发布变得更快更频繁。这种方式可以减少软件开发的成本与时间,减少风险。 而我对持续交付的一个较为抽象的理解是“一套软件工程方法论和许多最佳实践的集合”。方法论和实践都需要人去总结落地,所以,要想体会到持续交付的真正含义,就要在实际工作中贯彻和使用实践工具。 二、持续交付的价值 其最大的显性价值是,在实施持续交付后,能够做到在保证交付质量的前提下,加快交付速度,从而更快地得到市场反馈,推动产品的商业价值的实现。在互联网应用盛行、速度为王的今天,持续交付的价值更被突显出来。持续交付的能力,已成为评定一家互联网公司研发能力的重要指标。除显性价值外,如果站在不同角度看持续交付后的变化,我们还会发现一些隐性价值,而其中有一些影响甚至远远超过我们的预期。 1、通过快速灵活统一的环境构建...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL数据库在高并发下的优化方案
- Dcoker安装(在线仓库),最新的服务器搭配容器使用
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2整合Thymeleaf,官方推荐html解决方案