文章目录
- 基础篇
- 高可用指标4个9
- Arrays.asList()数组转集合Bug
- 1. 返回的列表是固定大小的
- 2. 共享底层数组
- 3. 列表转换为数组时的类型问题
- 解决方案
- 遍历集合时remove操作Bug
- 使用增强for循环（foreach）时的限制
- 使用迭代器正确地删除元素
- 对于LinkedList的特殊情形
- HashCode冲突
- 为什么会有哈希冲突？
- 如何解决哈希冲突？
- 如何减少哈希冲突？
- 总结
- Integer比较规则有坑
- 自动装箱与缓存机制
- 使用`.equals()`
- 总结
- 建议
- BigDecimal大坑
- 构造方法的选择
- 直接使用数字字面量
- 使用字符串构造
- 舍入模式
- 算术运算
- 使用`add()`、`subtract()`、`multiply()`和`divide()`方法
- 注意除法运算
- 总结
- List去重复元素
- 方法1: 使用Set
- 方法2: 使用LinkedHashSet
- 方法3: 使用Stream API
- 方法4: 手动遍历和检查
- ==和equals
- 示例:
- 传值还是传引用
- 基本数据类型（Primitive Types）
- 引用数据类型（Reference Types）
- 分析
- 示例
- Java中的深浅拷贝
- 浅拷贝（Shallow Copy）
- 深拷贝（Deep Copy）
- 实现方式
- 总结
- Junit
- Junit之AIR原则和断言assert初探
- AIR原则
- 断言（Assert）
- Junit之测试案例多样性很重要
- Junit之单元测试Coverage
- 测试覆盖率的类型
- JaCoCo与JUnit
- 如何使用JaCoCo
- 提高测试覆盖率
- 小结
- Junit之静态加载和方法加载
- 方法级别的加载
- 类级别的静态加载
- 注意事项
- Junit之浅谈自动测试框架设计
- 架构设计
- 模块化与可扩展性
- 集成与兼容性
- 性能与资源管理
- 结论
- Junit之借假修真Mock和Spy
- Mock
- 使用示例：
- Spy
- 使用示例：
- 总结
- JUC
- ThreadLocal如何结合线程池使用
- 线程池与 `ThreadLocal`
- 结合使用时的注意事项
- 解决方案
- 总结
- JUC之ThreadLocal父子线程无法共享传递
- JUC之InheritableThreadLocal父子线程传递
- JUC之TransmittableThreadLocal线程池数据传递
- 使用 `TransmittableThreadLocal`
- 示例代码
- 47.JUC之线程池优雅关停
- 1. 使用 `shutdown()` 方法
- 2. 使用 `awaitTermination()`
- 3. 使用 `shutdownNow()`
- 4. 中断和取消任务
- 5. 监听线程池状态
- 6. 配置线程池参数
- 7. 考虑超时和重试
- 8. 清理资源
- 48.JUC之线程池如何处理异常
- 1. 使用`Future`和`get()`方法
- 2. 设置未捕获异常处理器
- 3. 使用`RejectedExecutionHandler`
- 4. 在任务中捕获异常
- 5. 监听`Future`的完成状态
- 结论
- 数据结构和算法
- 如何评价一个算法好坏
- Mysql
- 建立高效复合索引
- 选择合适的列
- 创建复合索引
- 测试和优化索引
- 注意事项
- Innodb锁了什么
- 锁定的对象
- 锁的类型
- 锁的管理
- 死锁检测
- 性能与优化
- MySQL之回表解析
- 聚集索引和非聚集索引
- 回表过程
- 减少回表的策略
- 总结
- MySQL之大数据表如何新建索引
- 1. 分析需求和确定索引字段
- 2. 备份数据
- 3. 选择合适的时间窗口
- 4. 使用ONLINE DDL（数据定义语言）
- 5. 创建新表并导入数据
- 6. 监控索引创建进度
- 7. 逐步加载索引
- 8. 使用分区
- 9. 调整innodb_buffer_pool大小
- 10. 测试索引效果
- 11. 监控和调整
- 12. 清理和维护
- MySQL之删除重复元素
- 方法1: 使用子查询和ROW_NUMBER()或RANK()
- 方法2: 使用子查询和MIN()函数
- 方法3: 使用自连接
- 方法4: 使用REPLACE INTO
- 方法5: 使用TRIGGER
- 注意事项
- MySQL之千万级数据分页的优化
- 1. 使用主键作为偏移量
- 2. 预加载索引
- 3. 限制查询结果的列
- 4. 使用覆盖索引
- 5. 使用`BETWEEN`代替`LIMIT`
- 6. 使用滑动窗口
- 7. 异步预加载
- 8. 缓存结果
- 9. 使用分区分表
- 10. 优化查询语句
- 11. 使用流式查询
- 实施注意事项
- 项目实战
- AOP全部通知正常流程
- 通用接口详情统计
- 自研限流组件
- 步骤 1: 设计需求和目标
- 步骤 2: 选择或设计限流算法
- 计数器算法
- 漏桶算法
- 令牌桶算法
- 步骤 3: 设计组件架构
- 步骤 4: 编写代码
- 步骤 5: 集成和测试
- 步骤 6: 监控和优化
- 步骤 7: 文档和维护
- 自研Redis缓存组件
- 步骤 1: 定义缓存注解
- 步骤 2: 创建切面
- 步骤 3: 配置Redis
- 步骤 4: 使用自定义注解
- 步骤 5: 测试和调试
- 直播弹幕
- 后端实现
- 1. **消息队列和数据库**
- 2. **实时通信**
- 3. **负载均衡**
- 4. **反垃圾信息**
- 5. **权限管理**
- 前端实现
- 1. **WebSocket连接**
- 2. **弹幕渲染**
- 3. **用户交互**
- 4. **性能优化**
- 5. **兼容性和适配**
- 示例代码片段
- 总结
- 设计模式支付重构策略
- 1. 定义支付策略接口 (策略模式)
- 2. 实现具体的支付策略
- 3. 创建支付策略工厂 (工厂模式)
- 4. 设计支付处理模板 (模板方法模式)
- 5. 实现具体支付处理器
- 6. 使用支付处理器
基础篇
高可用指标4个9
高可用指标中的“4个9”指的是系统或服务的可用性达到99.99%的水平。这是一个业界常用的标准，用来衡量系统或服务的可靠性与连续运行的能力。具体来说，“4个9”的含义如下：
- 99.99% 的可用性：这意味着在一年365天中，系统或服务应该只有0.01%的时间处于不可用状态。
我们可以进一步计算出这具体意味着多少时间：
- 一年的总秒数：大约是31,536,000秒（如果不考虑闰年）。
- 不可用时间：0.01% 的时间等于 31,536,000 秒 * 0.0001 = 3153.6 秒，大约是52.56分钟。
因此，如果一个服务声称具有“4个9”的高可用性，那么它应该能够在一年中提供服务至少364天23小时59分07秒44秒，而只允许有大约52.56分钟的中断时间。这种级别的可用性对于许多关键任务系统和服务来说是非常重要的，因为它们需要确保几乎不间断地运行，以满足用户需求和业务连续性。
实现这样的高可用性通常需要精心设计的架构，包括冗余组件、负载均衡、自动故障转移、持续监控以及快速恢复机制等。例如，Redis使用哨兵机制来保证即使在主节点失败的情况下也能保持服务的连续性，从而达到高可用的目标。
Arrays.asList()数组转集合Bug
Arrays.asList() 方法用于将数组转换为列表，但使用时需要注意一些
