前言为什么我们开发的系统会有并发Bug,并发Bug根源到底是什么?在追问这个问题之前,先说一下一颗剽悍的种子对并发的看法,并发真是一个即熟悉又陌生的课题。...但这并不是让我陌生的地方,真正让我陌生的是为什么要加锁,加锁仅仅是解决问题的手段,而问题的根源是什么?为什么在多线程下会出现这些问题,为什么我们开发的系统会有并发Bug?...总结我们从追问为什么我们开发的系统会有并发Bug,从而知道了并发Bug背后其实是上下文带来的原子性问题和CPU缓存带来的可见性问题,以及指令优化带来的有序问题。...而并发Bug解决的手段是加锁,但不管是加的是什么样的锁;加锁要解决核心都是围绕并发Bug的根源。...所以理解了并发Bug根源到底是什么,更多是让你在使用锁时能意识到为什么要锁;就像开头所说从单体系统的使用Synchronized,Lock等锁,到分布式系统Redis、ZooKeeper的锁一直在变,可问题本质并没有变
这些 bug 无奇不有,从无法打开页面到数据奇怪丢失,麻木早已经替代焦虑成为了我们面对 bug 时的主要情绪。 但我时不时的抱怨依然是:为什么 bug总是在发生。...没有人希望看到 bug,我们不想,客户更加不想。但我们似乎都不愿承认的一个事实是: bug是代码的副产品而已。...原谅我用一个粗俗的比喻来解释为什么这么做行不通: 我们换来的只是打扫的速度,对制造垃圾的人产生不了任何影响,效果甚至会适得其反:考虑到总有人为他们收拾残局,我们的善后工作做得越好,他们越是会肆无忌惮。...铺垫了如此之多,我想表达的观点依然是老生常谈:质量内建,以及最近几年我们常常提倡的测试左移。至于什么是质量内建和测试左移,并不在这篇文章的范围内,你在网上可以找到大量的专业文章来介绍他们。...我想说的是: 质量不是「希望」的结果,它是付出的收获。关键在于你愿意用什么去交换。 提升质量的诀窍一点也不神秘。口口相传的各类业内实践便是最好的灵丹妙药,比如重构、代码评审、结对编程、流水线集成等等。
在学习《问题分析与解决》时学到了一种找到问题根源的方法——问五次为什么。具体内容是:当遇到一个问题,不要只看当前答案,要继续往下问,为什么,连问五次,就能够找到更深层次的问题。...最近在复盘bug的时候,也使用了这种方法,屡试不爽。 前端发布后,页面按钮点击失效,用户反馈问题,前端回滚代码后恢复。 问题一、为什么按钮点击会失效?...因为前端代码写出了一个bug,没有对空对象进行判空,导致页面js抛出异常,按钮失效。 一般到这里就结束了,把代码加上对象判空,继续发布就完成了。 但是大家集思广益,问五次为什么,看看是否有新的发现。...改进:「记录」日志时把key值写好,精简不需要的日志。 总结 经过问五个为什么,把一个看似简单的线上bug,挖出了更多可以修改的点。为以后及时发现问题,少出事故,做了很大的贡献。...如果只问一个为什么,那么修改的只有表象问题,把代码判断空加上就结束了。 问了五个为什么之后,做了这几件事: 修复代码判空的bug。 发现了日志系统的磁盘问题。 发现了系统的冗余日志,要精简掉。
最近在朋友圈流行了这样的一张小学数学题,当然结果是“出乎意料”,看似简单的结果,几乎很少有人作对,而分析下来的原因无非是惯性思维下的粗心导致完全错误,那么云层带大家分析下思考过程。...再算一次 Y+Z/2*X=5+2/2*10=15 对不起还是错的,因为最后一只猫少一个爪子,所以应该是Y+Z/2*(X-Z/2)=?...心中一万只草泥马奔过,再算一次 Y+Z/2*(X-Z/2)=5+2/2*(10-2/2)=14 其实大家会发现这个题目非常的“坑爹”,不就是故意折腾人么,但是在很多系统中,开发看到测试提出的Bug也是这样的感觉...作为开发就和我们成人一样看到问题总是以自己的世界观来理解,导致理所当然的就这样就对了,而真正真相就被隐藏了。 而儿童一般能够做对的原因是,老师有引导性的提示细心的重要性并且长期踩雷。...这也是测试人员和开发人员的区别之一,现在知道为啥测试不是谁都能做的工作了吧,开发也为啥找不到BUG了吧。
数学逻辑和计算机程序的代码,准确地说,是彼此的镜像。...然而,有些启示是深刻的,因为它们表明,曾经被认为是不同的两个旧概念,实际上是相同的。...柯里-霍华德对应(Curry-Howard correspondence)也做了同样的事情,但规模更大,不仅将一个领域的不同概念联系起来,而且将整个学科联系起来:计算机科学和数理逻辑。...也称为柯里-霍华德同构(isomorphism同构,是一个术语,意思是两件事之间存在某种一对一的对应关系),它在数学证明和计算机程序之间建立了联系。...在验证 8 能被 2 整除后,我们可以得出结论,8 确实是偶数类型的“居民”。 柯里和霍华德表明,类型在根本上等同于逻辑命题。
最近在朋友圈流行了这样的一个小学数学题,当然结果是“出乎意料”。看似简单的结果,儿童一般能够做对,而大人却几乎很少有人做对,分析下来,原因无非是惯性思维下的粗心导致的完全错误。...一般大多数的第一结果可能都是这样!等等,注意最后一个应该是Y+Z×X=? ? ? 心中一百只草泥马奔过,再算一遍 Y+Z*X=5+2*10=25 ? 对不起还是错的,因为猫爪从2只 ?...其实大家会发现这个题目非常的“坑爹”,不就是故意折腾人么。但是在很多系统中,开发看到测试提出的Bug也是这样的感觉。...作为开发就和大人做这道题一样,看到问题往往会以自己的惯性思维来理解,理所当然地认为就这样就对了,导致真相就被隐藏了。 ? 其实大家会发现这个题目非常的“坑爹”,不就是故意折腾人么。...但是在很多系统中,开发看到测试提出的Bug也是这样的感觉。作为开发就和大人做这道题一样,看到问题往往会以自己的惯性思维来理解,理所当然地认为就这样就对了,导致真相就被隐藏了。 ?
今天又看到一个和上次同类的问题,于是顺手一发,朋友圈继续炸裂,心中只能嘿嘿一笑!圣斗士不会吃同样的招数两次,但是无论是开发和测试都会在同样的问题上反复犯错。...注意:最后一个是X+Y*Z 心中一百只草泥马奔过,再算一遍 X+Y*Z=10+5*4=30 对不起还是错的,因为口哨的数目变了 所以应该是X+Y*Z/2=10+5*4/2=20 对不起还是错的,...因为猫少了个口哨 所以,应该是X+(Y-Z/2)*Z/2=10+(5-2)*2=16 其实大家会发现这个题目非常的“坑爹”,不就是故意折腾人么,但是在很多系统中,开发看到测试提出的Bug也是这样的感觉...作为开发就和我们成人一样看到问题总是以自己的世界观来理解,导致理所当然的就这样就对了,而真正真相就被隐藏了。 而儿童一般能够做对的原因是,老师有引导性的提示细心的重要性并且长期踩雷。...这也是测试人员和开发人员的区别之一,现在知道为啥测试不是谁都能做的工作了吧,开发也为啥找不到BUG了吧。
程序员调 Bug 的感觉 就是这样的一波未平,一波又起 千万不要和程序员直接说有 Bug 面对 Bug,一些程序员会生气,会沮丧,会心烦意乱,甚至会灰心丧气,而另一些程序员会依然保持冷静沉着。...因此,如何处理修复 Bug 的过程也值得我们细细琢磨。 ? 牛 X 程序员和 Bug 之间的 PK 大雄想分享一些程序员修复他们的源代码时所经历的想法。...这种汹涌澎拜的斗争是我经常要面对的,而且显然会困扰许多软件开发人员。 2.“为什么这个脚本需要这么多库?”...当我一筹莫展时,我往往会选择从头开始,因为这样才有可能找到完成项目 的正确道路。 ? 为什么程序员发现不了自己的 Bug? ?...小伙伴们有什么想说的 欢迎在下方评论区留言哦!
原文链接:http://wetest.qq.com/lab/view/348.html 一、什么是同构直出? 直出这个名词是在node出现后才有的,在node出现前叫做服务端渲染。...这里说明下:直出并不一定就比非直出快,但是它能保证用户在不同机型、不同网络条件下都有一个比较好的体验。 那什么是同构呢?...QQ兴趣部落拥有页面80多个,开发人员14个,参与改造直出人力2个,使用同构的做法无疑可以最大程度上降低改造和维护成本。 亿万级用户意味着什么呢?...三、同构直出的改造方案 接下来可以了解下怎样解决上面遇到的一些问题,以及部落同构直出的改造方案。...最终构建出来的目录大致是这样的,以a页面为例,有HTML模板、组件入口脚本、创建store对象的脚本,最后还有一个首屏action的脚本。 这个脚本是做什么的呢?
中国的程序员攻城师们遇到最难调试的bug是什么? 以下为程序员调试bug的种种传奇经历。...@王杰 百分之百出现的bug都是好bug,多线程里的有些bug能重现已经是一个惊喜了。。。...有一天出现了一个bug,查看打印日志,修改,第二天同样的bug又出现了,但是在不同的源码处。 继续添加日志,查看,修改,这过程重复了n次,每次出现bug的位置都不一样。...@放荡不羁爱自由 难倒计算机系同学的三大问题 3.为什么上不去网 2.为什么电脑打不开 1.为什么电脑这么慢 ? @树下一条河 最难调的BUG就是,策划:“感觉不对。”...联想到前几天的小护士,于是问院方半夜是否有人进入,答一些值夜班的护士会偶尔在里面休息。 于是找到进去的小护士,问是否动交换机,答没有,问进去后做了些什么动作,答只是睡觉。再追问,除此之外呢?
前言 逻辑性错误也是出现bug的重灾区,有很多是因为逻辑性比较复杂,这个倒是可以理解。但是,很多时候出现的问题查了半天最后真想给自己一巴掌。人傻没办法,自己折腾自己。因为这个问题实在太弱智了。...下面针对改bug的经历,做了个简单的分类。...bug,找了老半天。...很明显,还有许多该做的事情都没有做就跳出循环了。 像这样的错误还有什么时候容易犯呢?比如: "!" 非判断的时候,容易搞反了。 三目运算符,写错位置。...千千万万,来留言说一说你的bug吧!
程序员一生与bug奋战,可谓是杀敌无数,见怪不怪了!在某知识社交平台中,一个“有哪些让程序员目瞪口呆的bug”的话题引来了6700多万的阅读,可见程序员们对这个话题的敏感度有多高。...所以,为什么一定是500英里呢?且看大神讲解: ? 2 int mian() 这其实是一个书写上的错误,之所以会放在本文中,是因为很多程序员的职业生涯中都有过写!错!的经历!...Bug:条件里忘记添加”a.id=b.prio” 结果:临时表从预计的几千条达到了上亿条,数据库崩溃!!!! 8 足以让系统瘫痪的bug ?...10 据传,iPhone手机日历上的bug ?...13 比较弱智的bug 某网友:让我目瞪口呆的BUG是update不加where... 14 人类历史上第一个程序BUG ?
这两个bug分别出现在不同的项目中,但它们都是我在解决过程中学到了很多关于调试和解决问题的技巧。 问题一 第一个bug发生在一个Web应用程序中,这个应用程序使用了Spring Boot框架。...问题二 第二个bug发生在一个Android应用程序中。这个应用程序使用了Kotlin语言编写。当时,我们正在开发一个功能,允许用户在地图上选择一个点并获取该点的经纬度信息。...在测试过程中,我们发现在某些情况下,获取到的经纬度信息是不正确的。经过一番调查,我们发现这个问题是由于我们在计算距离时没有考虑到地球的曲率导致的。 为了解决这个问题,我们首先需要找到导致问题的原因。...同时,我们还需要在客户端对计算出的距离进行四舍五入,以保留两位小数。 通过以上修改,我们成功地解决了这两个bug。这两个经历让我深刻认识到了调试和解决问题的重要性。...在面对bug时,我们需要保持冷静,仔细分析问题的原因,然后采取合适的方法来解决问题。同时,我们还需要不断学习新的知识和技能,以便更好地应对各种复杂的问题。
一、什么是同构直出? ? 直出这个名词是在node出现后才有的,在node出现前叫做服务端渲染。...这里说明下:直出并不一定就比非直出快,但是它能保证用户在不同机型、不同网络条件下都有一个比较好的体验。 那什么是同构呢?...QQ兴趣部落拥有页面80多个,开发人员14个,参与改造直出人力2个,使用同构的做法无疑可以最大程度上降低改造和维护成本。 亿万级用户意味着什么呢?...三、同构直出的改造方案 接下来可以了解下怎样解决上面遇到的一些问题,以及部落同构直出的改造方案。 ?...最终构建出来的目录大致是这样的,以a页面为例,有HTML模板、组件入口脚本、创建store对象的脚本,最后还有一个首屏action的脚本。 这个脚本是做什么的呢? ?
程序员一生与bug奋战,可谓是杀敌无数,见怪不怪了! 在知识社交平台中,一个“有哪些让程序员目瞪口呆的bug”的话题引来了6700多万的阅读,可见程序员们对这个话题的敏感度有多高。...所以,为什么一定是500英里呢?且看大神讲解: 2、int mian() 这其实是一个书写上的错误,之所以会放在本文中,是因为很多程序员的职业生涯中都有过写!错!的经历!...6、某外资通信设备商的逆天bug(实在太长,给各位上图) 7、足以让数据库瞬间崩溃的bug 愿望:在百万量级的数据库里实现快速自我交叉匹配查询。 手段:建立临时表提速。...8、足以让系统瘫痪的bug 9、程序员都能看懂的bug if (object == null) { object.doSomething(); } else { object.doSomethingElse...13、比较弱智的bug 某网友:让我目瞪口呆的BUG是update不加where... 14、人类历史上第一个程序BUG
那我们该如何删除这些多余的 Tomcat Server 呢?强迫症总归是不舒服的,下面我们就来做一个小结。...,那就是服务没选择好,或是端口冲突的原因,这个时候就要关闭原有运行中的 Tomcat,再从 Server 窗口中选择正确的服务,这样问题即可解决。...链接如下: 启动 Tomcat 应用服务器端口 8080 被占用排查思路及解决方式 ---- 总结 在本文中我们解决了一个 Tomcat 初学者经常犯的错误:由于对 IDE 的操作不熟练而导致的 bug...,这类问题是可以通过长期的练习避免的,熟悉工具我们才能在开发中做到得心应手、事半功倍,发挥工具的便捷性。...---- 我是白鹿,一个不懈奋斗的程序猿。望本文能对你有所裨益,欢迎大家的一键三连!若有其他问题、建议或者补充可以留言在文章下方,感谢大家的支持!
文章目录 前言 一、错误原因分析 二、解决方式 总结 前言 可能有些同学在使用 Eclipse 进行项目开发的时候,存在对于 Tomcat 的错误操作,会发现在下面的工具栏里 Server 的选项里面有好多...那我们该如何删除这些多余的 Tomcat Server 呢?强迫症总归是不舒服的,下面我们就来做一个小结。...一、错误原因分析 出现多个 Tomcat server 的原因就是:在之前启动的程序中,在运行结束之后没有关闭 Server,而下一次启动该程序或者其他程序时,点击 Tomcat 的 run,再次启动了一个新的...,那就是服务没选择好,或是端口冲突的原因,这个时候就要关闭原有运行中的 Tomcat,再从 Server 窗口中选择正确的服务,这样问题即可解决。...链接如下:启动 Tomcat 应用服务器端口 8080 被占用排查思路及解决方式 总结 在本文中我们解决了一个 Tomcat 初学者经常犯的错误:由于对 IDE 的操作不熟练而导致的 bug,这类问题是可以通过长期的练习避免的
它不仅可以减少系统的状态数量(从而变得更简单),还能减少无效状态的数量!你的系统不需要处理这些无效状态,因为它们在你的程序中实际上是不可表示的。...这不只是一个小技巧,它可以极大简化你的系统,并防止出现各种类型的 bug。这有一些例子。...在某些情况下,正确而简单的代码是性能最好的代码! 真正的问题是程序员在错误的地方和错误的时间花了太多的时间在担心效率上。过早优化是编程中所有(或者至少是大部分)罪恶的根源。...重点学习: 纯函数式编程 关系型模型 规范的方法 逻辑编程 代数数据类型 类型类 (通用的和特定的) 借位检查器 (仿射 / 线性类型) 依赖类型 Curry-Howard 同构 宏 同像性(Homoiconicity...基于这个规则的函数“toggle”就非常简单。你可以读取其中一个值,并将两个值都设置为反向值。 现在,假设你将这两个变量放到不同的数据库中,并且不能再被一起修改,那么会发生什么?
RTL bug很大一部分原因是设计没有理解和预见到芯片的需求和使用场景,以及验证没有测试到相应的状态空间。 bug是不可避免的,需要设计和验证一起尽可能地把bug排除在芯片开发周期之外。...其中涉及到bug的预防和bug的检测。本文主要讨论芯片的bug预防。 bug预防 bug预防技术一般是从设计角度来说的,包括设计规范,代码 review,lint检查,单元测试。...所有的这些bug预防技术都有些根本的问题或者需要注意的地方: 问题1:“设计一般是同一个模块的糟糕验证 让设计寻找自己代码中的bug,这种方法的有效性很值得怀疑。...因为设计是从功能实现的角度出发,所以他们必然会有盲点。这就是为什么绝大多数公司都会聘用不同的人来验证电路,其实就是要求验证人员从不同于设计的视角来验证芯片,这样的验证过程不会带有开发人员的固有成见。...当然这里说的更多是狭义上的bug,例如,使用lint工具检查latch、cdc问题,很大程度上消除这方面的芯片bug。 如果高效地利用这些工具,芯片验证所需要的工作量就会相应减少很多。
你的系统不需要处理这些无效状态,因为它们在你的程序中实际上是不可表示的。 这不只是一个小技巧,它可以极大简化你的系统,并防止出现各种类型的 bug。这有一些例子。...在某些情况下,正确而简单的代码是性能最好的代码! 真正的问题是程序员在错误的地方和错误的时间花了太多的时间在担心效率上。过早优化是编程中所有(或者至少是大部分)罪恶的根源。...追求局部的简单性会导致全局复杂性的增加,而且是数量级的。 例如,使用较小的服务可以让这些服务变得更简单,但一致性的降低和对更多进程间通信的需求让系统变得更加复杂。...重点学习: 纯函数式编程 关系型模型 规范的方法 逻辑编程 代数数据类型 类型类 (通用的和特定的) 借位检查器 (仿射 / 线性类型) 依赖类型 Curry-Howard 同构 宏 同像性(Homoiconicity...基于这个规则的函数“toggle”就非常简单。你可以读取其中一个值,并将两个值都设置为反向值。 现在,假设你将这两个变量放到不同的数据库中,并且不能再被一起修改,那么会发生什么?
领取专属 10元无门槛券
手把手带您无忧上云