浮点数做运算会出误差的。
0.3+0.3+0.3 算出来的结果是 0.89999999999.
强行四舍五入精度不够的话，容易产生误差，假设一笔误差 0.00001 ，一天上百万笔交易金额产生的误差就会以千万为单位。。一年下来就是好几百万了。

@dingwen07
话说现在这个 winget 我有两个比较不满意的地方
一个是需要开代理
另一个有时候 windows 的安装过程是有一些选项的，winget 安装时候直接用的默认选项一步到底，事后配置麻烦。

单个用户频繁更新算不上并发。直接加行锁完事了。
就算一秒钟更新 20 下，行锁都是绰绰有余。
你觉得不合适大概率只是你自己觉得，跑一下压测就知道了，大多数情况只是杞人忧天。。

一般来说都是结合 http status 和业务状态码一起用的。
40x 系列表示这些请求已经进入到了应用内部处理，但是由于请求参数不对、权限不对、url 路径不对等原因应用内部返回了这些错误状态码。
50x 系列表示 http 请求中间经过的某个网关发生了异常、超时，或者请求已经进入到了应用内部但是应用内部出现异常等原因。

200 表示请求已经已经进入到了应用内部处理。至于业务里出现的一个错误码，比如余额不足、账号未实名认证啦这些，当然需要添加一个 code 表示异常错误来方便前端进行处理。

其实业务 code 和 http status 也有重叠的地方。比如查找 id=1000 的 book ，https://xx.xx/detail?id=1000 ，你就会去纠结到底是 404 还是弄一个业务 code 。我自己的偏好是 404 只用于 url 在后端是否有对应的 RequestMapping ，对于根据某某参数、条件查不到某数据的这种情况我喜欢放到业务 code 里。这样的话 40x 、50x 系列的 http status 的功能就更偏向于运维监控层面而非业务相关。而且这样还有个好处就是内容传输协议不再局限于 http ，我可以随时调整协议格式，比如采用 grpc ，我不需要再去考虑迁移协议后怎么兼容原来 http 404 的问题，因为我的数据返回的业务 code 里已经涵盖了 http 404 的这种情况。

前端这边肯定是先进行 http status 判断，然后再进行业务 code 判断。

说到底还是因为 http status 这东西已经出现了几十年了，跟不上现在的互联网应用变化，所以国内的设计都是以实用角度出发，存粹把 http 协议当成是一个传输的载体。现在很多公司做的接口甚至都把 url 部分废弃掉了，需要访问哪个接口把服务名称写进 http 参数里交给后端做分发。

github 早期的 url 是很 restful 的，后边规模大了，也开始不 restful 了。也就 V2EX 上一群没见过世面的小学生喜欢把 restful 挂嘴上。

我 2018 macbook pro ，插着电源用了一年，循环不到 30 次，结果电池容量就已经只剩 85%。
长期插着电源并不是什么好事。

最好的方法就是扩展 spring ，
同时 accept 接受 application/json 和 application/x-www-form-urlencoded 两种 request ，
这样你们爱传啥传啥。

nodejs 前边几年吹的很厉害，前后端一把梭。
经过几年时间的检验，nodejs 在后端届并没有展现出杀手级的应用，反而还被异军突起的 go 和 k8s 杀了一道。
现在 nodejs 基本已经沦落为用来 js 打包、本地 webpack 调试一类的支持工具了。。。

其实 AQS 的本质其实就是双向链表+LockSupport.park()和 LockSupport.unpark()实现的同步器。单看 enq 并没有什么卵用，你还得结合 shouldParkAfterFailedAcquire 、unparkSuccessor 、setHeadAndPropagate 、cancelAcquire 几个方法一起看。

任意时候 node 状态都会发生变化，所以针对链表的操作用了大量的 forloop+cas 操作来保证并发安全。jdk8 版本的这个 AQS 应该是经过了 N 个版本的修订才会搞得这么零零散散一堆方法。。

我记得 8 版本以后的某个版本好像 aqs 有大篇幅的重写。。

优秀的程序员：
出现需求->寻求市面上成熟的解决方案->出现疑虑困惑->通过各种途径解决使用困惑->问题属于硬伤无法解决->有能力则自己造轮子，没能力退而求其次选择其他方案

抠脚程序员：
出现需求->寻求市面上成熟的解决方案->选择 ES->ES 出现问题->换 SOLR->SOLR 出现问题->自己研究 LUENCE->能力有限研究不出来->？好像 pg 也有 full text search ？-> 感觉不好用->再次换回 ES

认为这种写法好的显然是不写单元测试的那种。三个嵌套 if 你就能搞出 2^3=8 种分支，你有精力去写这么多的 test-case 吗？

能写出这样代码的一般都是逻辑很混乱的那种，不会去整理思考分支结构的前因后果，然后 debug 的时候发现空指针或者报错，然后顺势往里插一个 if 来解决问题。。

概念意义上来说，dns 是通过域名换取主机 ip 地址。实现上包括 DNS 报文协议和传输协议，但是概念上并没有规定 dns 的传输实现一定要基于 udp 。

只不过最开始搞 dns 服务实现的人采用了 udp ，然后这个东西推广开了默认成为了事实标准，只不过他没有想到如今的网络安全问题会这么严重。

我之前下了一单 32G 16 寸，后来想想还是退了。。。
intel mac 够我用了，不要给自己加太多需求。

以前有买过。但是不用了。
请问这个东西除了把你的菜单栏占的满满的以外，有什么意义吗？

@christin 都是一样的。

@kikione intern 能解决单机上边的问题，那么如果机器不只一台呢？

Integer a = 999992;
System.out.println(a.toString()==a.toString());

你 run 一下就会发现这个结果在 jdk1.8 以上就是 false 。
不是所有字符串都会建在常量池里

你这有问题。
你如何保证值相同的 userId 字符串对应的是同一个对象？

这东西跟 restful 一样，本身属于是一种架构设计风格。
他们最大的缺陷就是在于想象很美好，现实很骨感。
一旦落地到实际应用里，真按照规范来操作反而会异常的别扭。
所以我的建议是对这些规范适当借鉴吸取，而非全盘照搬。

我很讨厌那些没敲几年代码水平一般，但是整天把 restful 规范挂嘴上的人，一天到晚没事干跑到版面争论业务 code 和 http status code 要不要分开的问题。《狗头》