2023.9.4 内存分配与回收策略、Redis优化业务

又到周一，这数据库课还要按规定位置坐，老师还喜欢游走。马德，写个力扣好像在高中上课玩手机一样。老规矩，先讲力扣。

---

写了两道，都是贪心算法

第一道，经典跳跃问题，用贪心算法写，只关注能跳到的最远距离，并且暂定为当前位置，遍历数组，寻找最远的位置，当最远位置大于数组最后一位时返回true。而假如出现了某个位置curr无法到达，说明终点也是无法到达的，直接返回false。

第二道，上一道的变体，问最少多少步能到达，题目默认测试用例都可以到达最后一位，我觉得不严谨，加了一个判断，无法到达终点就返回false。因为多了一步要计算步数，所以不能像上一题一样无脑让curr往前冲，先派出next"探路"，curr到达之后再+1，途中next继续更新最远距离，总体还是贪心算法来解。

---

下午，睡过头了，信息安全概论不上也罢。补了下上午没看完的《深入理解JAVA虚拟机》，总结下内容吧。

昨天看的介绍垃圾收集器还剩一点没看完，今天主要讲的是要根据业务具体情况选择垃圾收集器，不是说越快就一定越好。文中举例了Epsilon收集器，它是以不进行垃圾收集为"卖点"的一款收集器。在部份中小服务中，jvm可能会在内存没耗尽的情况下就退出，而此时如果进行GC无疑是浪费的。

“Epsilon也是有着类似的目标，如果读者的应用只要运行数分钟甚至数秒，只要Java虚拟机能正确分配内存，在堆耗尽之前就会退出，那显然运行负载极小、没有任何回收行为的Epsilon便是很恰当的选择。”

剩下的就是内存分配与回收策略，昨天一不小心就写了三千字，人麻了，长话短说：

1、大多数情况下，对象优先在新生代Eden取中分配，当Eden区没有足够空间进行分配时，虚拟机将会发起一次Minor GC；

2、大对象直接进入老年代，大对象指需要大量连续内存空间的Java对象，比如很长的字符串或者元素数量很庞大的数组。假如碰到存活时间很短的大对象那更是麻烦，容易导致内存明明还有空间就要GC，以便获取空间来安置他们，复制对象也是很高的开销。通过虚拟机的参数可以使大对象直接进入老年代，避免来回复制浪费资源；

3、长期存活的对象将进入老年代，这个是满足强分代假说的。对象在Eden区中诞生，经过一次Minor GC后仍存活，会被转移到Survivor区中，并将其年龄设置为1岁，在Survivor区中没存熬过一次Minor GC，年龄就会增加1岁，当增加到15岁（默认）就会进入老年代，因为对象头中存储分代年龄的大小是4比特，所以只能记录到15岁，而年龄阈值是可以修改的；

4、动态对象年龄判定，上面讲的是比较死板的年龄判定方法。除此之外，当Survivor区中低于或等于某年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，而无需达到年龄阈值；

5、空间分配担保，在发生Minor GC之前，必须进行一系列操作，这堆操作讲起来有点绕，我画了个图来方便理解：

---

接着就是继续写《黑马点评》，跟高并发有关的已经做完了，剩下两天就是用Redis做的一些业务优化了，我实习时候做的业务逻辑要比这复杂多了，所以就不多做讲解了，直接看总结吧。

收工。