树街猫o(=•ェ•=...：CMS收集器：是一种以获取最短回收停顿时间为目标的收集器。 它的收集过程分为四部分： 初始标记、并发标记、重新标记、并发清除 优点：并发收集、低停顿。 缺点： 1.对CPU资源敏感。并发的时候，它虽然不会导致用户线程停顿，但是会因为占用了一部分CPU资源而导致应用程序变慢，吞吐量降低。 2.无法处理浮动垃圾。并发清除阶段，用户线程还在继续运行而产生的垃圾，这部分垃圾只能等到下一次GC才能进行回收 3.空间碎片，因为CMS收集器是基于标记-清除算法的，如果需要分配大对象的话，找不到足够大的连续内存空间来存放当前对象，很可能需要提前触发一次Full GC。 G1收集器： 运行过程分为四个步骤：初始标记、并发标记、最终标记、筛选回收。 优点： 并行和并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。将Java堆划分为多个大小相等的独立区域。 空间整合：从整体来看是基于标记-整理算法实现的收集器，从局部来看是基于复制算法实现的收集器。不会产生内存空间碎片。 可预测的停顿：G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内。这是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。 区别： 使用范围： CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用 G1收集器收集范围是老年代和新生代。不需要结合其他收集器使用 STW时间： CMS收集器以最小的停顿时间为目标的收集器。 G1收集器可预测垃圾回收的停顿时间（建立可预测的停顿时间模型） 垃圾碎片： CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片 G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。 垃圾回收的过程不太一样。

Thpffcj：是菠萝同事的情况下

树街猫o(=•ェ•=...：我用的是window，虚拟桌面。 win+ctrl+D创建虚拟桌面 win+ctrl+F关闭当前虚拟桌面 win+ctrl+左/右→切换虚拟桌面 骚一样的操作，一个虚拟桌面放你工作的东西，另一个摸鱼，来回切换

不知道做算法还是做p...：看到自己的答案，差点没笑死.........

又戈月空：一、版本规划阶段 要求产品经理的规划提前当前开发 1~2 个版本。可以让团队知道下一步具体做什么，有助开发提前考虑代码框架，避免后期返工。可以快速开启下一版本迭代，同时提高项目的可控程度。 需要明确版本目的、做哪些需求、具体怎么实现，初阶产品最好跟产品内部讨论确认一遍，避免方向性错误。重点在于围绕迭代目的进行需求筛选和真伪判断，并按优先级进行排序，同时注意合理规划需求量，避免迭代周期太短或者过长。一般情况下，稳定的版本迭代周期控制在2~4周内。 二、需求评审阶段 1. 需求确认 在团队内讨论迭代方案的合理性和可行性，及时发现问题，避免返工修改。如果时间比较紧，不方便召集团队集体讨论，就需要在版本规划阶段主动联系对接人员进行讨论确认。 2. 原型评审 方案通过后，开始绘制原型，并召开原型评审。评审会议上需要明确版本目的，先讲为什么，再讲怎么做，让每一位成员都能对版本需求有个全面的理解，减少后续不必要的沟通。对于功能复杂或比较大的版本，在初次评审后，往往会发现比较多的问题，需要会后重新确认和修改方案，进行二次评审。产品经理在这一阶段要做的是认真考虑多方意见，给出一个合理完善的方案。 三、工期评估阶段 一般会给半天到一天的时间用于评估工期。评估的时间节点包括设计、开发、提测、验收和发布。评估完成后由产品经理汇总，并基于迭代节奏协调开发时间和需求量，确认最终的需求和各个时间节点，同步给整个团队。最终需求确认下来后，就可以创建当前版本的需求池，并分配对应的研发人员和开发时间。 四、开发测试阶段 测试同事开始准备测试用例，并召集开发和产品一起讨论，确认对需求理解无误。版本提测后，产品经理需要跟进功能完成情况和bug修复情况，判断没有完成的功能和bug是要加班、砍需求还是规划到下个版本，并着手准备版本更新日志，递交翻译，为发布做准备。 五、验收阶段 一般需要预留1-2天时间，对新版本进行验收，确保需求按要求实现，设计师需要进行视觉还原，保证视觉效果。 六、发布阶段 开发完成验收后的 bug 修复后，提交发布包，进行一轮回归测试，由产品验收通过后，与相关运营人员进行对接发布版本。版本发布后，一般情况下还需对线上的新版本进行一轮验证，没问题就可以推送版本升级通知。另外，需要整理更新日志和发布结果同步给团队成员，整理上一版本遗留问题、进行版本复盘、准备后续效果评估及下一版本迭代工作。

树街猫o(=•ェ•=...：我只知道Mysql的隔离级别。。 读未提交：读不加锁，写加行锁，可能会脏读。事务中的修改，即使没有提交，对其他事务也都是可见的。事务可以读取为提交的数据，这也被称为脏读。 举例：用户A修改了数据（未提交commit事务），而用户B能读到A修改后的数据。 读提交（不可重复读）：读写加行锁，读完释放，写加独占锁（排他锁），因此写时不能进行读操作，避免脏读。一个事务从开始直到提交之前，所做的任何修改对其他事务都是不可见的。这个级别有时候也叫不可重复读，因为两次执行同样的查询，可能会得到不一样的结果。 举例：用户A修改了数据（未提交commit事务），而用户B不能读到A修改并且未提交的数据。当用户A提交事务后，用户B才能读到A修改后的数据。 可重复读：（Mysql默认隔离级别）读时加共享锁，事务结束时释放，即其他事务必须等该事务结束才能更新操作，这样防止了不可重复读 可串行化：会在读取的每一行数据上都加锁，可能导致大量的超时和锁争用的问题。

树街猫o(=•ェ•=...：IP地址的形式应该是：(1~255).(0~255).(0~255).(0~255) 使用什么数据类型，应该根据业务需求来。 1.简单粗暴，直接使用varchar 2.根据算法，将IP地址进行换算，如果是Java，获取到的IP地址应该是String类型，可以使用split()方法进行分割，从而将IP地址每一位换算成整数。例如： ipBytes = ip.Split('.'); for (int i = ipBytes.Length - 1; i >= 0; i--) { num += ((int.Parse(ipBytes[i]) % 256) * Math.Pow(256, (3 - i))); } 所以可以用int或者long类型来存储，这样存储也容易判断IP地址的范围