作为互联网工作资深社畜，来分享我的看法。   互联网大厂   我身边有不少人进去，也许进大厂是互联网行业里面可以傲视群雄的象征、是一个互联网工作者的较高荣誉，告知别人时，自己和家人脸上都有自豪和耀眼的光，可观的薪酬待遇，更是大多数人都向往的。但工作压力和工作时间，你真的欣然接受吗？如果能把握好甚至只能勉强地把握，我觉得你真的不用问这个问题，好好工作，争取能做出属于自己的贡献，而不是沉默在不缺人才的互联网时代。   体制   也只是一份工作，而且很体面，大概率也是很舒心的工作。中国大多父母依旧倾向自己的儿女可以不用过于辛苦，他们培育大家读书，目的就是想让儿女能安逸地生活，可能他们会支持你做任何不...

若无法通过并行流实现并发，则必须创建并运行自己的任务。运行任务的理想Java 8方法就是CompletableFuture。 Java并发的历史始于非常原始和有问题的机制，并且充满各种尝试的优化。本文将展示一个规范形式，表示创建和运行任务的最简单，最好的方法。 Java初期通过直接创建自己的Thread对象来使用线程，甚至子类化来创建特定“任务线程”对象。手动调用构造函数并自己启动线程。创建所有这些线程的开销变得非常重要，现在不鼓励。Java 5中，添加了类来为你处理线程池。可以将任务创建为单独的类型，然后将其交给ExecutorService运行，而不是为每种不同类型的任务创建新的Threa...

想必，最近大家都听到很多裁员消息，看着身边的朋友，不少被裁，究其原因，公司因为业务发展不好，只能强行辞退来降本。不仅包括很多应届生毁约，还有 21 届大量裁员，不少资深元老级员工也被辞退，于是很多同学也开始担心自己，每天开始面试，也准备离职了。       上级领导频频被换，组织架构时常变更，每个人的工作压力都很大，说好的年终奖缩水或者不发，晋升渠道延期或者关闭，很多人不知道自己还要不要坚持下去。      不过，今年一起苟住，只要疫情过去，就业形势还是好的。

1 细数当年乱世坑     毕业近年，去过很多公司，算得上是资深社畜。但我也是一路坑 ️，一路衰，后来想想真的是年轻的我太傻了。   先说一些我遇到的坑，希望后续求职的小伙伴们，未来的鲜嫩小社畜可以避避坑。     实习只是协议，不是劳动合同，可以随时开了你，尽量去能大概率转正的地方做实习生！不然大都是浪费时间，给你的都是杂活烂活，没有任何提升。   签劳动合同前，务必问清楚工资的构成，基本工资（人们常说的base）、绩效工资、年终奖，除此之外，还有各种福利（餐补、交通补贴），加班费（大部分公司只有调休），年假多少天，五险一金（是否按照全额工资为基数进行缴纳，缴纳系数因城市不同而不同）等等。 ...

1 动机 复杂的条件逻辑是编程中最难理解的东西之一，因此我一直在寻求给条件逻辑添加结构。很多时候，我发现可以将条件逻辑拆分到不同的场景（或者叫高阶用例），从而拆解复杂的条件逻辑。这种拆分有时用条件逻辑本身的结构就足以表达，但使用类和多态能把逻辑的拆分表述得更清晰。  2 常见场景 2.1 构造一组类型，每个类型处理各自的一种条件逻辑 例如，我会注意到，图书、音乐、食品的处理方式不同，这是因为它们分属不同类型的商品。  最明显的征兆就是有好几个函数都有基于类型代码的switch语句。若果真如此，我就可以针对switch语句中的每种分支逻辑创建一个类，用多态来承载各个类型特有的行为，从而去除重复的...

1 动机 有时发现这样一串条件检查：检查条件各不相同，最终行为却一致。 这时就该使用“逻辑或”和“逻辑与”将它们合并为一个条件表达式：  合并后的条件代码会表述“实际上只有一次条件检查，只不过有多个并列条件需要检查，从而使这一次检查的用意更清晰。当然，合并前和合并后的代码有着相同的效果，但原先代码传达出的信息却是“这里有一些各自独立的条件测试，它们只是恰好同时发生” 这项重构往往可以为使用【提炼函数】做好准备。将检查条件提炼成一个独立的函数对于厘清代码意义非常有用，因为它把描述“做什么”的语句换成了“为什么这样做”。  条件语句的合并理由也同时指出不要合并的理由：若我认为这些检查的确彼此独立，...

老粉们都知道，我是19年秋招入职华为的，如今也是工作近三年的老油条了。  1 工作日常 快来站会了！PL一把从位置上站起来。不舍手中的包子，迅速开始今天的敏捷开发。开完会，条件反射地打开IDEA放在一边，然后刷起知乎。 还没一会，导师让我优化一个数据库，这一看就是连接字段不加索引？小数类型还用float？为了性能这个字段明显可以冗余的呀！这varchar长度1000？居然用text类型粗糙你？这几张表哪个 zz 建的？一看，哦是我刚入职前写的啊。 下午继续搬砖，测试突然问我你这请求怎么就500了？我瞅了下监控，这NPE是谁给我搞出来的？  这几百行的方法里居然有十几个if else，用状态者模...

消息队列解析(2)-MQ选型 1 选型标准 1.1 开源（白嫖） 方便修改源码，而非阻塞等待软件提供商猴年马月发布下个版本解决。 1.2 生态（大家一起玩） 方便找到很多问题的解决方案，和主流框架也无缝对接。 1.3 确保消息可靠传递 1.4 Cluster 高可用性。 1.5 性能 具备足够好的性能，能满足绝大多数场景的性能要求。 于是市面上主要就如下可供选择： 2 RabbitMQ 2.1 优点 Erlang编写，最早为电信行业系统可靠通信设计，是支持AMQP协议的消息队列之一。相当轻量级的消息队列，非常容易部署和使用。号称世上使用最广泛的开源MQ。 灵活的路由配置 和其他MQ不同，它在生...

每条SQL语句，MySQL都会经过成本和规则的优化，对这个SQL选择对应的一些访问方法和顺序，包括做一些特殊的改写确保执行效率是最优的，然后优化过后，就会得到一个执 行计划。 执行计划，落实到底层，无非就是先访问哪个表，用哪个索引还是全表扫描，拿到数据后如何回表，是否要基于临时磁盘文件做分组聚合或者排序。 简单的单表查询，可能这就一条数据，代表它打算如何访问这一个表。 explain select * from t1  这里直接会扫描表的聚簇索引的叶节点，按顺序扫描过去拿到表里全部数据。 rows=32，说明这个表里就32条数据，全表扫描会全扫出来 filtered=100%，无where过滤条...

1 回表的性能消耗 无论单列索引 or 联合索引，一个索引就对应一个独立的B+索引树，索引树节点仅包含：  索引里的字段值 主键值  即使根据索引树按条件找到所需数据，也仅是索引里的几个字段的值和主键值，万一你搞个select *，那就还得其他字段，就需回表，根据主键到聚簇索引里找，聚簇索引的叶节点是数据页，找到数据页才能把一行数据所有字段值读出来。  所以类似 select * from table order by xx1,xx2,xx3 得从联合索引的索引树里按序取出所有数据，接着对每条数据都走一个主键的聚簇索引查找，性能不高。 有时MySQL执行引擎可能认为，你要是类似 select ...

平时执行的更新语句，都是从磁盘上加载数据页到DB内存的缓存页，接着就直接更新内存里的缓存页，同时还更新对应的redo log写入一个buffer中。   既然更新了BP里的缓存页，缓存页就会变成脏页，就得有时机把那脏页给刷到磁盘文件，脏页刷盘机制，是维护了一个LRU链表。 后续若要加载磁盘文件的数据页到BP，但此时并无空闲缓存页，就得将部分脏缓存页刷入到磁盘，此时就会根据LRU刷盘。 万一你执行查询，需查大量数据到缓存页，可能导致内存里大量脏页需淘汰刷盘，才能腾出足够内存执行这条查询SQL。这时可能发现突然莫名线上DB执行某查询SQL就突然性能出现抖动，平时只要几十ms查询，这次一下子要几s，...

水友们大清早都是积极交流技术，你确定不要一起来嘛~

多个事务同时并发更新一行数据时， 就有脏写问题。脏写绝对不允许，可依靠锁机制让多个事务更新一行数据的时候串行化，避免同时更新一行数据。 有个事务要来更新一行数据，他会先看这行数据有没有人加锁？看到没人加锁，该事务就会创建一个锁，包含自己的trx_id和等待状态，然后把锁跟这行数据关联在一起。 更新一行数据，必须将其所在数据页从磁盘文件读到缓存页才能更新，所以此时这行数据和关联的锁的数据结构，都在内存。  因为事务A给那行数据加了锁，所以此时该数据被加锁。就不能再让别人访问了！ 此时事务B也想更新那行数据，就检查当前这行数据是否被别人加锁，然后发现事务A抢先给这行数据加锁了，这可咋办？ 事务B想...

1 访问Buffer Pool时需要加锁吗？ 对MySQL执行CRUD的第一步，就是利用BP里的缓存来更新或查询。 假设MySQL同时接收到了多个请求，他自然会用多线程处理，那这多线程就可能会同时访问BP，即同时操作里面的缓存页，同时操作一个free链表、flush链表、lru链表。现在多线程来并发的访问这个BP，此时他们都是在访问内存里的一些共享数据结构，如缓存页、各种链表，必要加锁，然后让一个线程先完成一系列操作，比如说加载数据页到缓存页，更新free、lru链表，然后释放锁，接着下个线程再执行操作。 2 多线程并发访问加锁，DB性能还能好？ 即使就一个BP，多个线程会加锁串行执行，性能也...