每天努力Coding

要知道直接内存是在操作系统中的，gc回收不能回收jvm以外的空间，这是怎么一个回事呢，实际上java底层有一个类叫unsafe这个类用于管理和控制直接内存的分配和回收。在构造bytebuffer时候就会获得这个unsafe对象，在最后调用一个Cleaner对象的clean对对象进行回收，里面涉及到了虚引用。可以买两本Nosql的书，完善数据库方面的知识，全方面的了解数据库，了解KV了解搜索引擎。软引用就是当强引用没了之后，如果内存不够会被回收，阻塞IO和非阻塞IO ，一个有等待，一个没有等待。

其实如果加的锁是业务名字+用户ID的话不管单例还是集群都会出现锁的误删，单例中没有考虑主要是因为有synchronized锁和乐观锁把所有问题解决了，没有用到Redis锁，锁的时候根本不看名字的，但是集群中哪怕对比线程ID都会出意外，两个计算机可能会有相同的线程ID访问同一个业务就会出现问题。首先，分布式锁先要考虑一个问题就是分布式锁一定要所有服务都能访问一把锁，这把锁就可以是Redis的锁，Redis是单线程直接存在线程之中访问快能够最大程度上提升整体的访问效率。一人一单，一个人只能下一单。

为什么路由模式，最后的队列配置会配置在消费者身上，仔细思考，其实队列是对我们进行了隐藏，我们无法直接干预队列的操作，那么在消费者身上却可以非常方便的进行注解配置，直接读取注解然后进行标注即可。expire代表redis键的存活周期，值为-1代表永久有效，这里考虑热键问题，如果一个值多次被访问，设置为热键，周期为永久，不然其他都设置对应一个周期时长，-2代表该值已经过期。jedis线程本身并不安全，创建消耗过大，所以需要创建jedis连接池，这和远程调用和数据库德鲁伊的原理是一致的。

通过配置饿加载的名称，所以application的名字在负载均衡中有着极为重要的作用。如果说不设置这个字段，JVM默认也会取生成这个字段，序列化就是对象封装好传输出去，默认懒加载，第一次建立负载均衡控制，而饥饿模式下则会立刻创建，降低第一次的访问时间。悲观锁就是很悲观，数据并发获取时先认为会出现问题，对数据进行保护，而后进行修改。乐观锁认为并发冲突不会那么巧，先修改了，改完了看一下校验一下对不对就OK。说明类被更改了，类无法成功转化，那么就会造成传过来类不一致问题，

一周学习内容及总结