第九周作业

垃圾回收的原理



什么时间垃圾回收？

垃圾回收机制是在虚拟机空闲的时候或者内存紧张的时候触发



什么样的对象会被回收？

会回收已经释放掉在内存中没用的对象，比如某个对象没有被任何活跃的线程访问，也没有被任何对象所引用。程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点



如何回收？

对于没用的对象垃圾回收器是通过标记计数法和根搜索法来判断的



哪些可以作为GC Root？

1.虚拟机栈（栈帧中的本地变量表）中引用的对象；

2.方法区中的类静态属性引用的对象；

3.方法区中常量引用的对象；

4.本地方法栈中JNI（即一般说的Native方法）中引用的对象



秒杀系统设计

秒杀主要解决两个问题： 并发读 和并发写

并发读的核心优化理念是尽量减少用户到服务器端来“读”数据，或者让他们读更少的数据

并发写也是一样的原则，最终目的都是尽量的减少数据库的操作，数据库操作是这个问题的瓶颈点，所以一般会单独独立一个库作 做秒杀操作



在整个从用户请求路径上，从浏览器到服务端尽量遵循几个原则

1、数据量尽量少（能缓存和提前的数据尽量缓存）

动静分离，把静态数据缓存到距离用户最近的地方（用户浏览器、CDN或者服务器端Cache中）

静态数据修改为直接缓存http请求连接，连head 和body都不需要解析

CDN和缓存在浏览器的区别，缓存在浏览器中基本不可控了，缓存在CDN可以主动失效，有一定的控制权

2、请求量尽量少（尽量动态数据才请求，合并请求文件）



3、路径尽量短

静态数据尽量提前推送到CDN



4、依赖尽量少



5、不能有单点



在redis中添加计数器，比如秒杀商品为9000个，前10000个用户提交订单成功，10000个以后的用户直接返回秒杀结束，未抢到，然后到用户付款部分，前9000个付款用户付款成功就代表秒杀成功，每一层进入到服务下层的请求尽可能的少，到最后数据库层要通过事务和版本号，和正整数类型来防止超卖



为了满足以上的需求，设计上要尽量的满足： 动静分离、热点的发现与隔离、请求的削峰填谷和分层过滤



减库存会涉及到大量的mysql并发，所以一般的秒杀场景建议秒杀商品单独一个数据库，进行物理上的隔离，这样能够有效防止秒杀场景对于正常的业务的影响

减库存的数据一致性一般有两种方案：

第一种： 在应用程序中通过事务来判断，即保证减后库存不能为负数，否则就回滚；



第二种： 是直接设置数据库的字段数据为无符号整数，这样减后库存字段值小于零时会直接执行 SQL 语句来报错



减库存在mysql数据库中会存在行级别并发锁的问题，如何解决

1、应用层做排队。按照商品维度设置队列顺序执行，这样能减少同一台机器对数据库同一行记录进行操作的并发度，同时也能控制单个商品占用数据库连接的数量，防止热点商品占用太多的数据库连接。



2、数据库层做排队。应用层只能做到单机的排队，但是应用机器数本身很多，这种排队方式控制并发的能力仍然有限，所以如果能在数据库层做全局排队是最理想的。阿里的数据库团队开发了针对这种 MySQL 的 InnoDB 层上的补丁程序（patch），可以在数据库层上对单行记录做到并发排队。



下单和扣库存两个操作的事务性是怎么做的

可以分两步来做，先创建订单但是先不生效，然后减库存，如果减库存成功后再生效订单，否则订单不生效