牛市容易暴跌, 熊市容易暴涨. 体会体会.

这条件不全呀, A 拿着 Q 要更新的时候, B 也想更新怎么处理呢?

你先找到工作再说吧.

dev 和 pro 都独立了还能在 dev 上开发然后合到 pro 上?

一般这种情况我们都是直接干掉 dev 从 pro 重新拉一个. 和正在开发的人都周知下.

fat jar

搞论坛没戏. 第一步怎么做审查就能卡死你.

有个简单的办法是, 兜底释放, 占用时间是有上限的. 到了上限时间一定会被释放. (可以搞个定时任务扫到期的任务, 就算是某一次释放失败了下一次也能成功)

但上面这个方法时效性不够, 而且某些场景下不适用

时效性强一点可以考虑兜底去补偿. 方法也很多, 一种可行的是, 释放后, 直接发一个延迟检查的消息, 短暂时间后收到检查消息看看是不是真的释放了, 如果没有再释放一次, 并且再发这个检查消息, 比如重复发三次. 如此一来还会无法得到失败的场景就基本不存在了. (可以再结合上面第一种兜底到时间一定释放, 保证万无一失)

这里面可再做改进的是, 可以当数据库更新失败后(无论是返回为 0 或者抛了异常), 可以原地直接重试释放, 然后再发检查消息

这里面有个注意的点, 需要有个标记记录, 只能释放自己获得的资源, 否则会出现, A 释放了资源, B 获取了资源, A 获得延迟检查消息, 发现资源被占用, 把 B 占用的资源释放了. 可以多一个字段直接是一串随机数(uuid 就行), 延迟检查消息要带着这个 uuid 去释放, 对不上说明已经被其他人重新占用了, 不用再释放.

绑 86 手机号是不是就把你拦住了?

看你自己呗, 这也算是个出国的机会.

你要是想, 就可以开始准备.

不想的话, 早点分手吧.

所以用户还需要有个心理准备是, 油门会突然变刹车? 随便一想就知道事故会更多.

两个角度. 一是收不到注册短信, 应该就没人能注册了, 这样"新用户注册量"应该会有明显下跌(甚至长时间跌 0), 负责这块需要有监控. 二是短信包用完了, 负责这块要么是有剩余短信量不足的监控, 要么是有短信包用完的提醒.

不过小厂这些都没有也不稀奇.

计算机比生化环材好考公.

java 是值传递, 对象传的是指针.

基本类型在 java 里确实特殊, 和对象不是一回事

至少淘宝的促销阿里是不出钱的, 全靠商家出钱.