这是个 Vue 项目, 当看到这个 TypeError: Cannot read properties of undefined(reading 'key') 这行报错的时候，我的第一反应是 v-for...绑定的 key 有问题？...初步分析 这个 Vue 项目侧边栏是登录后根据用户权限数据动态渲染出来的，侧边栏菜单深度达到三级，动态绑定的部分涉及到 v-for 的嵌套使用，侧边栏点击的时候会不会是那里的 key 有问题导致的，由于之前这个项目也了解一些...，这是我当时的第一反应，然后 K 给了我确定回复: 这个key我查了，没问题 2.png 那侧边栏点击对应的页面里的 中有没有相关的key数据绑定异常？...OK，但是项目里所有页面有分页的组件的地方都得改，第一时间向上反馈，领导了解情况后同意，这次现场支援任务完成 总结 这次的问题虽然困扰了K几天，其实这个问题并不难，解决后发现也没有用到什么高深技术，重要的是遇到问题用纯工程化的思维去把思路理清楚
作者：水墨寒 掘金ID：https://juejin.cn/user/3051900006317549 在解决算法问题中我们会经常遇到要求均等概率的问题， 以leetcode 470....⚠️ 不讨论最优解，只讨论算法思路 看到均等概率的问题， 我们最先要想到转成2进制来处理，思路是让均等概率转换成均等概率出现0和1， 再由 0 和 1 ，增加位数来处理均等概率的其他数。...1 : 0 } 现在我们有了过渡函数 Rand2 , 那么我们使用随机生成4位二进制数那么我就会得到 一个 均等生成 0 ～ 15 的函数 function Rand15(): number {...Rand10() 函数， 我们只要舍弃掉 10～15 就可以了 function Rand10(): number { let num: number // 使用do while 循环 遇到小于10...的结束循环返回结果，遇到大的继续 roll do { num = Rand15() } while ( num > 9) return num + 1 // 别忘记 + 1 } 这道题解决完了
大家好，又见面了，我是全栈君 这个问题对中国的失真N多人见面。那里N多解决方案。这是一个问题，我中遇到，只记得。...周围环境： 1、Centos 2、JDk1.7 3、Tomcat7 4、git 5、ant1.9.4 现象： 1、java源码是utf-8编码的，但当中的中文输出是乱码； 2、我的webapp默认要求显示英文...，但显示中文（有些内容是从属性文件里读取的）。..."zh_CN.UTF-8" LC_MEASUREMENT="zh_CN.UTF-8" LC_IDENTIFICATION="zh_CN.UTF-8" LC_ALL= 3、vim java源码中文没有问题...encoding=“UTF-8” 2、改动tomcat的启动脚本start.sh,最前面增加：export LANG=en_US 注意：不要改动用户的默认语言了。
我知道时差 8 小时，是因为有时区问题。 我知道时间差 1 小时，是因为有夏令时的原因。 但是这里差了 5 分 43 秒，有零有整，就让我有点摸不着头脑了。...这个 10 年前被提出的问题居然已经被浏览过 746k 次了，非常热门的问题了，我居然没注意到过： 这个问题具体是这样的： 你就大概瞟一眼，我给你翻译翻译。...跑出来怎么是 1 秒呢，毫无毛病啊： 我甚至怀疑是 jdk 版本的问题，于是我换了 jdk 9,11,15 都跑了一下，都是 1 秒。 这就很奇怪了啊。 感觉这个问题提的就有问题啊。...，官方是这样回复的： 这个问题不会被修复，以避免任何兼容性问题。...意思就是：问题我知道了，但是这玩意不太好弄，bug 先变成 feature 吧，就先这样吧。 别问，问就是有历史原因在里面。 第二个冷知识是，前面提到的，时区在 1927 年发生了变化。
这时他表示：“你看，我调用合约的查询接口，查出来Alice的余额确实是10000，这就不对了嘛，而且，链还在出块，根本不防篡改嘛！”。 初步分析和解答 为何这类问题最近多起来了？...所以，热点问题浮出水面，前提是用户可以更方便地修改底层数据了，而不是这个问题之前不存在。...“能否篡改整个联盟链” 有的同学可能会继续刨根问底：“那我多修改几个节点的数据是不是就篡改了？”，一般提出这个问题的同学是面向他自己部署的开发测试环境，所有节点都在他手上，所以可以随便改。...这种改法，听起来需要不少力气活，但对于一个有决心、有能力的篡改者来说，改改本地数据这个事情其实并不难，难的只是去改别的机构数据而已。...关键是，这并不解决问题，因为从数据被篡改后到检测出来的时间窗里，哪怕脏数据只存在了几十毫秒，但这时如果不幸有应用来查询数据，依旧会得到篡改后的结果。
，今天我要分享的这个 case 就是个典型，废话不多说，进入正题。...问题描述 前端同学发现新开发的项目接口有 1/3 概率出现 RTT（请求往返时间）大于 3 s 的情况，以登录接口为例，Chrome 请求所花时间如下 ?...服务端排查 我们的 server 端是一个 Spring MVC 服务，对于登录接口来说，它的逻辑如下 @RestController @RequestMapping(path = "/api/auth...trace 执行的结果（MVC 服务执行时间 80ms 左右）与前端请求有 1/3 的概率超过 3s 的结论告诉了运维，让他们排查一下从反向代理层到站点层这中间是否有啥问题，不一会儿果然查出了问题。...，如果我早知道有这么一个选项，就可以一步到位排查出此问题了 知道了问题所在，处理方案就很简单了，直接把这台有问题的机器从 kongfu 摘掉就行了 总结 排查的思路其实相对比较清晰，但一定要对请求的整个流转流程有一个比较清醒的认识
定位问题 前阵子群里有个同学@我，让我分享下平时是怎么定位问题的，以及排查问题的思路。 甚至我还看到有的面试题也会问这种问题（是不是在校验真的做过线上项目？）...最近组内来了个新人实习生，正好我前几天也给他讲了我的排查问题步骤，今天来分享下我的经验。 这篇文章主要给还未参加工作的小白看的哈。...网络的东西都是虚拟的，你们要是感兴趣，我改天再细讲。 谨慎地记录日志。...生产环境禁止输出 debug 日志；有选择地输出 info 日志；如果使用 warn 来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。...但这不重要，反正有地方看请求链路信息就好了。 如果是自己写的代码，那自己也大概能猜出是什么原因造成的了。 如果不是自己写的代码，找到监控的入口，往上游追踪并看入参，一般也能定位到问题。
对于 Dubbo 来说， waitForResultIfSync 方法，是主链路上的方法。 我个人觉得保守一点说，可以说 90% 以上的请求都会走到这个方法来，阻塞等待结果。...所以如果该方法如果有问题，则会影响到 Dubbo 的性能。 Dubbo 作为中间件，有可能会运行在各种不同的 JDK 版本中，对于特定的 JDK 版本来说，这个优化确实是对于性能的提升有很大的帮助。...前面只是一个引子，本文不会去写 Dubbo 相关的知识点。 主要写写 CompletableFuture 的 get() 到底有啥问题。 放心，这个点面试肯定不考。...等着别人问起来的时候，你再娓娓道来。 或者不经意间看到别人这样写的时候，轻飘飘的说一句：这里有可能会有性能问题，可以去了解一下。 啥性能问题？...再说一次：Dubbo 作为开源的中间件，有可能会运行在各种不同的 JDK 版本中，且该方法是它主链路上的核心代码，对于特定的 JDK 版本来说，这个优化确实是对于性能的提升有很大的帮助。
来源：公众号【编程珠玑】 作者：守望先生 ID：shouwangxiansheng 多线程，作为一个开发者，这个名词应该不陌生。我在《对进程和线程的一些总结》中也有介绍，这里就不详述。...同样的，如果有一个任务特别耗时，而这个任务可以拆分为多个任务，那么就可以让每个线程去执行一个任务，这样任务就可以更快地完成了。 代价 听起来都很好，但是多线程是有代价的。...由于它们“同时”进行任务，那么它们任务的有序性就很难保障，而且一旦任务相关，它们之间可能还会竞争某些公共资源，造成死锁等问题。...在《一个奇怪的链接问题》中提到，对于非glibc库中的库函数，都需要显式链接对应的库。...也就是说，创建线程的时候，传入的参数必须确保其使用这个参数时，参数没有被修改，否则的话，拿到的将是错误的值， 总结 本文通过一些小例子，简单介绍了线程概念，对于绑核，多线程同步等问题均一笔带过，将在后面的文章中继续介绍
先说一下我遇到这个问题的思路: 思路1. 首先最容易想到的就是使用UIWebView...."不想偷懒的程序员不是优秀的程序猿", 秉着这种想法,自然就是希望后台的兄弟们能够提供一个URL给移动端进行调用,直接用网页的形式进行展示就完事啦....不过这里有三个需要处理的问题: 1> UIWebView...使用CoreText编辑图文混排是没问题啦,但是考虑到...展示图文混搭的界面....我先下楼透透气...好吧,你可能想到了解析html. ...因此使用CoreText需要一个HTML的解析器.... 这个让我再想想...于是.......思路3.UITextVIew 在iOS7之后,苹果封装了基于C语言的CoreTextKit,推出了UITextkit...用起来更加OC化. 但在思路2遇到的问题这个依然存在...后来....
目录 解决 解决 打开控制面板 📷 📷 📷 就可以启动了
事情是这样的，前两天有个小伙伴问我：「为啥我的 webpack 运行完看不到我写的页面，而是：」 ? 嗯？文件列表页？好吧，这种情况我似乎没遇到过，一下子没法给出答案，只能要来关键代码： ?...emmm，成功勾起我的好奇心了，虽然写过一些 Webpack 源码分析的文章，但 webpack-dev-server 确实不在我的知识范围，好在我有秘籍《如何阅读源码 —— 以 Vetur 为例》，是时候展示真正的技术了...第三步：分析问题 按照现有的情报，加上我对 HTTP 协议的理解，可以基本推断问题必然是出在 webpack-dev-server 框架处理首页请求的逻辑上，大概率是 output.publicPath...嗯，我觉得靠谱，那就沿着这个思路挖一挖源码，找到具体原因吧。...我去。。。也不少啊，这看起来太费劲了，我只是想找到这个 bug 的原因，没必要全看吧！那就直接搜关键词 publicPath 试试吧： ?
全文 3000 字，欢迎点赞转发 事情是这样的，前两天有个小伙伴问我：「为啥我的 webpack 运行完看不到我写的页面，而是：」 嗯？文件列表页？...emmm，成功勾起我的好奇心了，虽然写过一些 Webpack 源码分析的文章，但 webpack-dev-server 确实不在我的知识范围，好在我有秘籍《如何阅读源码 —— 以 Vetur 为例》，是时候展示真正的技术了...嗯，我觉得靠谱，那就沿着这个思路挖一挖源码，找到具体原因吧。...) 函数，注入静态资源服务功能，如果这个中间件运行的时候按路径找不到对应的文件资源，会调用下一个中间件继续处理请求，看起来跟我们的问题没啥关系。...也不少啊，这看起来太费劲了，我只是想找到这个 bug 的原因，没必要全看吧！
第一次出现：是thrift的python client去请求server，发现偶尔出现这个问题 第二次：接入第三方的api，去请求数据时，发现一个接入方的api第一次总是报这个错，当时又没有做处理，导致获得信息置空...第三次：最近去抓appstore的应用指数又重新出现该问题，使用HttpRequestRetryHandler 重试，设置到20次都无一次成功。...该异常在客户端和服务器端均有可能发生，引起该异常的原因有两个，第一个就是如果一端的Socket被关闭（或主动关闭或者因为异常退出而引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect...简单的说就是在连接断开后的读和写操作引起的。 经多次测试发现，50个线程并发，最大的连接时间超过了90秒，平均请求结果仅有400KB，很奇怪的现象。...猜测是appstore端连接时间过长直接断开连接（是我被连90s也要断啊）。修改下超时，只能让请求更快恢复， RetryExec.execute 时仍然无法正常连接。
小勤：大海，为什么我这两个简单的表建立数据关系有问题啊？ 大海：啊？出什么问题了？...小勤：你看，我先将表添加到数据模型，这是订单明细表的： 用同样的方法将产品表也添加到数据模型，然后创建表间关系，结果出错了！ 大海：你的产品表里的产品名称重复了。 小勤：啊？...我看看： 小勤：真的嘢！里面有两个小米，一个是宏仁生产的，一个是德昌生产的。但是，产品名称重复不行吗？ 大海：当然不行啊，你产品名称是重复的，我怎么知道订单明细表里的产品应该对应你产品表里哪一个啊？...小勤：啊，知道了，看来我还是得把订单明细表里的产品ID放出来，不然做出来的数据分析都是不对的。 大海：很棒，这么快就想到产品ID的问题了。...小勤：你上次《表间关系一线牵，何须匹配重复拼数据》的文章里不是有提醒吗？只是我没想到我的数据那么快就存在这种情况。 大海：呵呵，名称重复的情况太正常了，所以尽可能都用ID编码。
循环依赖 假设我们有两个包：p1和p2。当包p1依赖包p2，包p2依赖包p1时，就会产生循环依赖。真实情况可能会更复杂一些。...调试循环依赖 比较尴尬的是Go语言并不会告诉你循环依赖导致错误的源文件或者源码信息。因此当你的代码库很大时，定位这个问题就有点困难。你可能会在多个不同的文件或包里徘徊，检查问题出在哪里。...为什么Go中不显示导致错误的原因呢？原因是在循环依赖中并不是只有一个源文件。 但Go语言会在报错信息中告诉你导致问题的package名，因此可以通过包名来解决问题。...解决循环依赖问题 当你遇到循环依赖问题时，先思考项目的组织关系是否合理。处理循环依赖最常见的方法是interface，但有时你可能并不需要它。...需要记住：强耦合的包可以合并成一个，这样比通过interface解决依赖循环更好，但对于一般情况，一般需要通过interface来解决循环依赖。
为了能够早点上线，早点回家，所以这个 Bug 就显得十万火急了，因为就这一个问题，其他都没问题，解决好了就可以上线了，于是开启了破案之路。...也就是请求到达 B 之后解码出来的已经是 HashMap 了，那么问题肯定是调用方传输的参数有问题。 ?...Dubbo内部参数查看 第四步：排查调用方代码 在调用方这边发起请求前，查看了参数对象，发现这个时候参数已经出问题了，字段类型发生了变化，所以问题就出在这里，都是老代码，应该都没改过，而是事实却被改了，...Http请求错误 第五步：BeanUtils 问题排查 归根到底还是 copy 的问题，我做了个小实验，如果是 Address2 copy 到 Address 是不会出问题的，只有嵌套的对象才会出问题。...FastJson解码失败 结局 找到原因后解决就是分分钟的事了，通过这个问题还是说明了加任何的代码都有风险。剩下的就是开发的锅了，加了代码没有自测，好在有测试把关，否则就凉凉了。
第一个问题 第一个问题是这样的： 他的图片，指的是文章中的这个部分： 当时我也没有细看，所以我的回复是 timeout 是个配置项，我这里取出来都是 30000 的原因是因为我没有进行配置。...然后，他对于问题进行了进一步的描述： 我点到源码里面一看，好家伙，它是这样写的： int timeout1 = getTimeout(invoker2, invocation); int timeout2...文章里面对于“随机选择两个”出来这个动作的代码实现，我感觉是有 BUG 的，所以提出了一个大胆的质疑： 但是秉着“又不是不能用”的核心思路，当时也没有细想。...当我前面的那个 pr 被 merge 的时候，我决定：要不好人做到底，把这个 BUG 也帮它们修复一下吧。 首先，我来详细解释一下，我为什么会认为这个地方有 BUG。...而在我的潜意识里面，第一次看代码的时候，我一直以为这个部分的代码就是 ==，所以我一直按照 == 进行的分析，从而觉得它有问题。 这波，我觉得得让潜意识来背锅。
面试官：「你是怎么定位线上问题的？」 这个面试题我在两年社招的时候遇到过，前几天面试也遇到了。我觉得我每一次都答得中规中矩，今天来梳理复盘下，下次又被问到的时候希望可以答得更好。...下一次我应该会按照这个思路去答： 1、如果线上出现了问题，我们更多的是希望由监控告警发现我们出了线上问题，而不是等到业务侧反馈。所以，我们需要对核心接口做好监控告警的功能。...6、如果不是系统告的警，是业务侧反馈出了问题，那这时候需要业务侧明确是哪个具体的功能/接口出了问题，有没有保留请求入参，有没有返回错误的信息，有何现象 7、知道了问题的现象之后，就需要根据经验排查可能是哪块出了问题了...11、要是不能复现，只能在怀疑的地方打上详细的日志再好好观察（问题定位不出来，很多时候就是日志不够详细，而日志在正常情况下也不应该打太多） 这个我估摸想要考察的是看看你平时是怎么去定位问题的，定位问题的思路是什么...话虽如此，这也只是我这几年的定位问题的模式，也未必对，也不知道有没有缺少了哪一个重要的环节。面小公司总体下来会问些方法论的多，不会很专研某项技术的问题。 我瞅瞅还有啥可以拉出来复盘下，继续写呗。
支付系统内的每一个请求都应该谨慎处理，而对于无法确定结果的超时请求更不能轻易确定终态，绝对不能像一个简单的网页请求一样重试一次。...终态判断处理问题 返回码映射 终态的判断应该是支付系统内最重要也是最容易踩坑的地方，这个处理的复杂程度真的太依赖三方系统的状态码设置了。...对于一个返回码设计良好的系统，如微信、支付宝，有业务结果码和明细错误码之分，我们进行终态判断和返回码映射时，可以首先以业务结果码为准，在业务结果为失败时，再去检查明细错误码。...如果请求受理时为超时，那么便可以认为是网络问题没有发送成功了，有时候还是要对自己的代码有一些信心的。...，再进行查询就是无意义的； 隔日账问题 隔日账问题在对账过程中不可避免，由于服务器时间有差异，交易处理也需要时间，在凌晨附近发生的交易可能会遭遇此问题，这会给对账造成一定的困扰，但合理的处理方式不会有太大的问题
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
