@dejavuwind #13 这种问题插入 CPU 调度就没必要了，一个线程细粒化到微指令时确实会在不同的核中执行，就如你说的同一时刻只能在一个核中运行，在考虑只是资源利用的情况下，确实就是只利用到了一个核的资源，至于是哪个核其实并不重要。题主这个问法自动帮他归纳为核的利用上，而不是使用上，不用揪他那几个字的意思

我老婆 4 月份剖腹产，貌似麻醉搞得不够好，她说感觉到医生在掏她肚子

@boywang004 一个东西达到垄断地步，用户体验权重早就下降几个层级。

多年前还有人歌颂微信体验好，朋友圈这么大体量没有广告。商业行为只是迟早的事而已，先获客再收割。每次打开朋友圈看到广告就像吃屎一样难受，朋友之间的一方净土硬是给我拉上一坨。所以为了不主动吃翔，不发朋友圈且不看。
公众号改版也是，我只想通过自己的渠道去关注有深度的号然后主动获取知识，现在加了推荐的没关注的文章，而且也有广告。

山海经确实可行，猎奇点够足。聊斋志异就别想了，到时候出来了就是钟馗抓卫

@lurui45 我京东订购的悦鲜活 950ml ，一般等活动能到 12-13 一瓶，一周送一次。不过很多人都不认可它是巴氏奶，保质期 19 天，我个人的感觉是口感非常不错。
国内很多巴氏奶我都尝试买过给孩子喝，比这个好喝的就香满楼的娟姗奶，缺点就是贵，有时间逛大型超市会买点喝。

看正版软件有没有识别你们公司的公网 IP ，我公司经常会被一些正版软件警告说用了非商业版或盗版的软件，然后 IT 部门会通知所有人检查电脑并且卸载掉。如果是竞品软件，只要在公司用了基本上都会被警告，所以一般有分析竞品软件的需求，都要求在无网络机器上进行。
至于 IDEA 一般情况下不会识别，我现在就在用 RustRover 个人免费版，没有搞商业项目，就单纯研究技术。如果到时候 IT 通知卸载了，我再干掉它就好了

这种场景我不去搞数据库持久化层，我弄分布式锁去锁线程，一般用 Redlock 。
你这个功能锁的 key 会定义为 uid_type_date ，然后网络服务中请求没有抢到锁且超过重试次数后就拒绝这次请求，返回系统繁忙之类的。而你这个场景的差别就是必须要重试到成功为止，可以加个 redis 做缓存层去搞重试，先记录到缓存中，保证缓存 get set 原子性就可以不用去在意重试多少次，失败的同时又有请求过来就一直往缓存加次数就好，成功就清 0 ，甚至数据实时性不高还可以定时处理，减轻数据库负担。
原理就是这样，里面一下细节就需要自己斟酌了，例如缓存 key 的定义，时间交叉点的问题。

@oldersnail #65 对不起，我跟你年龄差不了多少，你无法代表我们这一代人。你客观讨论问题可以细细讨论，触碰你儿时的痛并不是我的本意。

@oldersnail 行业耕耘这么久了理解能力不至于这么差呀，人家只是表达你这岁数入行时的行情比现在好很多，并且高薪多年积累的财富也不会少，按正常岁数发展购房也是买在了早期房产红利期。你搁这扯自己的家庭条件，你现在奔 7 我倒是可以理解你吃了改革开发初期时的苦

@Mrun #22 暑期工我做过多种多样的工作，基本都是重复性长时间的体力劳动。而码农时期 996 、通宵、单休这个我都长时间经历过。
前端后端对项目负责管点人、项目出问题导致宕机老板损失了很多钱也都有体验。
现在不加班，工作压力不大刚好在经历。
而你的所有言论都是在网上信息渠道所获取的，程序员在网上的发言权太大了，而且也有自己的信息茧房，很难体会到底层人员的辛苦。
你也别总是但是了，这些但是全是你自己想象的，并不是通过实践得出得经验。当你做了那些底层长时间体力劳动时，你就会发觉不止身心疲惫，而且没了自由。程序员所谓的脑力支出，非常辛苦，其实它是自由的，没人能限制你的思维，但是肉体却很容易被限制。
我这辈子都不会想回去做那些底层长时间体力劳动的工种，哪怕是一天。

3 楼的做法最简单了，在数据一致性的情况下，任务执行往 redis 写个 key ，完成 del 一下，进程 0 启动那里加个查询，拿到 redis 里的 key 执行对应的定时任务就可以了

这个事我比较有发言权。说到底这个问题的本质是社会问题，并不是个体问题。
我现在一胎随我姓，二胎随我老婆姓，很大程度上是一胎是儿子，才能很顺利两夫妻决定二胎随老婆性，如果一胎女儿，我也很难去处理二胎随我老婆姓，除非我什么都不在乎，不在乎父母的关系，不在乎亲戚朋友的看法，只能怪我修心程度不够，俗人一个。所以其实就是现在父系社会的一个问题，并不是我的问题。
然后讨论随谁姓的问题，只能是我跟我老婆根据情况自个讨论，无论是我父母或者是岳父母，最终只是告知他们我们夫妻的决定。小姨子就不应该讨论这个问题，这个是涉及未来几十年家庭生活非常重要的问题，外人有点自知之明就该闭嘴。

@YienX #18 小型私企直接默认工资包含了为老板提供情绪价值的钱。工作只为了赚钱，职场上的同事老板只是某一段时间的过客，没必要在意这么多屁事，不妨碍自己拿到工资就行。让他们爱说啥就说啥，谁上头谁输。
做好自己的本职工作，有余力多贡献一点也不要觉得吃亏，对得起职业道德，对得起自己的内心就足够了。曾经一个 UI 设计时老是被老板指手画脚，后面她悟了，说项目是做给老板的，并不是做给客户的，别老是把自己当作公司的主人公，面向老板设计。

订阅模式跟赠送时长底层逻辑上就有冲突，逼着别人把订阅关了去用赠送的，不然一直订阅的人根本用不上，而一旦有取消订阅的动机就代表用户已经准备脱坑，要么就是下单订阅然后立刻取消订阅薅羊毛。只能说做产品也是要经过大脑的，还不如搞些优惠券来得实际。
至于技术方案，这种方式的核心逻辑越单一越好，产品是无时无刻不在变化，维护越复杂的核心逻辑最终会导致产品的发展而写越多的特殊情况。建议只维护一个到期时间，购买订阅或者订阅自动扣费回调等其他所有形式的增加时长通过消费唯一凭证去处理，过期了就按当前时间加，未到期就叠加。
然而你说的为了方便用 expires_date_ms 作为过期时间，我看不出为啥会方便，订阅的到期时间只是其中一种支付方式的属性，为啥要跟系统的核心体系的过期时间挂钩。

这个可以从计算机组成 + 操作系统的知识来分析。
CPU 只是负责执行指令，而运行时间长短应该不会影响到 CPU 内部 3 级 Cache 的命中率，不过有可能随着时间的堆叠进程或者线程慢慢变多导致 Cache 频繁的置换从而使 Cache 命中率下降。当然也有可能这种情况会导致中断指令频繁。
然后就是内存，这个是大概率的原因了，刚开机的内存就是一大块，随着运行时长内存碎片化是不可避免的，然后碎片化整理肯定花费时长，不过这点我觉得应该影响不是特别大。
主要可能是很多软件的设计问题，随着运行时间的增加，内存占用一直增加，就例如我用 webstorm 内存老是用久了内存会增加到它不应该用到那么多内存的量级。多进程争抢内存也会导致很多内存会放在虚拟内存中，结果就是内存命中率下降，操作系统内存置换算法也要时间，就最终会感觉到电脑没有刚开始的流畅。
总结：内存命中率下降。