垃圾回收基础什么是垃圾没有任何引用指向的一个对象或多个对象（循环引用）叫做垃圾。 如何定位垃圾引用计数：引用计数为0的对象标记为垃圾，无法解决循环依赖 GC roots： JVM stack, native method stack, runtime constant pool, static references in method area, Clazz 从GC roots开始遍历所有对象，遍历不到的对象标记为垃圾 常见的垃圾回收算法这里说垃圾回收算法，其实叫垃圾回收思想更合适，因为实际垃圾回收算法都是借鉴了这些思想。 标记清除（Mark Sweep）：找到所有垃圾后清除 优点是实现简单，缺点是容易产生内存碎片。 拷贝（Copying）：将内存一分为二，只使用其中一份，垃圾回收时，把非垃圾对象拷贝到另一份内存，然后把第一份内存清掉 优点是没有内存碎片，缺点是浪费空间。 标记压缩（Mark Compact）：找到所有垃圾后清除，然后把存活对象压缩到一起消除碎片 优点是没有内存碎片，缺点是效率偏低。 JVM内存分代模型jdk1.7：年轻代（You ...

延时任务实现方案业务场景我们买火车票或者叫外卖的时候，下完单之后会跳转到支付页面，页面里通常会有一个计时器，要求在指定时间内完成支付，否则订单就会被自动取消。这就是延时任务的一个典型业务场景。分析这个场景，其实最关键的就是如何在订单超时的时候立即触发取消订单的动作。 那么如何实现这种延时业务呢？通常有以下4种方案。 定时任务轮询db用户下单后db中会生成一条订单记录，记录了订单号、用户ID、创建时间、订单详情、订单状态等信息。假设超时时间是600秒，我们后台起一个定时任务，每隔固定时间运行一次，每次扫描db中的超时订单select * from order where createTime <= now()-600，然后取消查询到的订单。 这种方法实现简单，但是有很多缺点。超时时间通常是秒级的，如果定时任务每秒运行一次，那么就相当于每秒就要对订单表做一次扫描，这是相当消耗db资源的操作，因此定时任务一般不会设置为秒级；但是如果设置为分钟级，又会牺牲即时性，比如600秒超时，很有可能660秒的时候订单才被取消。 DelayQueueJDK的D ...

业务场景分析业务场景：商品秒杀、商品抢购、群红包、抢优惠券、抽奖、买火车票 业务特点：瞬时售空、瞬时并发高、持续时间短、一般是商品定时上架 技术特点：读多写少、高并发、资源冲突 技术特点分析读多写少：秒杀系统请求数量巨大，但是真正抢到资源的请求很少，所以是读多写少。使用缓存减缓对后端的压力，比如利用CDN将图片等页面静态资源缓存掉。 高并发：秒杀系统最关键的就是要利用限流，把大多数请求挡在外面；负载均衡将请求分摊给各个后端；利用消息队列中间件做异步削峰；缓存缓解后端压力。 资源冲突：保证关键资源（如商品库存）的原子操作。数据库锁（乐观锁、悲观锁），分布式锁（redis、zk），利用redis decr的原子操作。 请求链路分析一次秒杀请求，首先是由客户端发起的，经过网络链路到达负载层，再由负载层分发到后端服务层，服务层处理业务逻辑之后，最终结果反映在数据库上。那么我们分析一下在整个请求链路上，针对秒杀系统，我们都有哪些解决方案。 客户端层：客户端呈现的秒杀页面中包含的图片、音乐、商品详情等静态资源，可以在客户端缓存起来，避免每次都要请求服务端而 ...

分布式环境下的ID生成策略考虑的维度在选择ID生成策略时，通常要根据不同的业务场景考虑下面几个维度： 全局唯一性：ID是否需要全局唯一 高并发下的高可用性：ID的生成需要支持高并发，保证高可用性 趋势递增：ID生成一般要趋势递增（不一定要严格递增），这样作为数据库的主键时可增加性能 信息安全：ID中不要泄露用户敏感信息，如手机号、生日等比较明显的信息 4种策略UUID：java的UUID.randomUUID() 数据库自增ID： 利用DB自身的自增能力，比如mysql中，auto_increment_increment=3表示每次ID增加3，auto_increment_offset=1表示ID从1开始增加； 在数据库集群中，如果没有一个中心化的ID生成器，那么就需要依赖各个数据库节点自行生成ID了，这个时候一个办法就是在各个节点中设置相同的auto_increment_increment，设置不同的auto_increment_offset。比如集群中A、B、C共3个db节点，3个节点的increment都设置成3，offset分别设置为1、 ...

elastic-job分片策略elastic-job在选举出主节点后，会由这个主节点进行作业分片，也就是要把每个作业的每个分片按照某种策略分配到各个作业执行节点上去。elastic-job默认提供了三种分片策略： AverageAllocationJobShardingStrategy：基于平均分配算法的分片策略 OdevitySortByNameJobShardingStrategy：根据作业名的哈希值奇偶数决定IP升降序算法的分片策略 RotateServerByNameJobShardingStrategy：根据作业名的哈希值对服务器列表进行轮转的分片策略 可以通过在配置作业的时候指定job-sharding-strategy-class来选择分片策略。 对于只有一个分片的作业，或者分片数小于作业执行节点数的作业，以上三种分片策略都会把分片分配到某一台或几台节点上去，会有固定的几台节点完全得不到分片，而elastic-job只有在节点变动（如加机器、节点崩溃退出）的时候才会重新分片，这就意味着如果初始分片不均匀的话，整个系统负载不均衡的 ...