qq_24991197的博客

业务场景：查询商品详情页的逻辑比较复杂，有些数据还需要远程调用，必然需要花费更多的时间。假如商品详情页的每个查询，需要如下标注的时间才能完成。那么，用户需要 5.5s 后才能看到商品详情页的内容。很显然是不能接受的。如果有多个线程同时完成这 6 步操作，也许只需要 1.5s 即可完成响应。Future 是 Java 5 添加的类，用来描述一个异步计算的结果。你可以使用isDone方法检查计算是否完成，或者使用get阻塞住调用线程，直到计算完成返回结果，你也可以使用cancel方法停止任务的执行。

Java泛型的总结学习

<!-- 引入redis --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> <exclusions> <...

常见数据库设计范式包括：第一范式，第二范式，第三范式及BC范式，当然还有第四及第五范式不过这里我们会把重点放到前三个范式上，这也是目前我们大多数数据库设计所要遵循的范式。数据操作异常及数据冗余数据冗余是指相同的数据在多个地方存在，或者说表中的某个列可以由其它列计算得到，这样就说表中存在着数据冗余。第一范式(1NF)定义：数据库表中的所有字段都是单一属性，不可再分的。这个单一属性是由基本的数据类型所构成的，如整数、浮点数、字符串等。换句话说第一范式要求数据库中的表都是二维表。第二范式(2NF

整体方向JVM 内存结构，和 Java 虚拟机的运行时区域有关。Java 内存模型，和 Java 的并发编程有关。Java 对象模型，和 Java 对象在虚拟机中的表现形式有关。JVM 内存结构Java 对象模型Java 对象自身的存储模型JVM 会给这个类创建一个 instanceKlass，保存在方法区，用来在JVM层表示该 Java 类。当我们在 Java 代码中，使用 new 创建一个对象的时候，JVM 会创建一个 instanceOopDesc 对象，这个对象中包含了对象头以及

通用性能优化口诀缓存异步批处理mysq| 应用优化写操作：批量insert,批量updateSq|编译N次和1次的时间与空间复杂度网络消耗的时间复杂度磁盘寻址的复杂度读操作：索引主键查询千万条记录1-10ms唯一索引千万条记录10-100ms非唯一索引千万条记录100- 1000ms无索引百万条记录1000ms+单机配置优化max_connection = 1000mysql 执行引擎先不是操作数据而是记录日志undo/redo 日志顺序写操作.

DNS用CNAME解析到源站整个的一个商品详情页，先加载静态资源后通过 ajax 请求获取商品详情页内容渲染的方式，任何一步没做到位，都会拖累整个系统 tps/qps 的一个响应现在的静态请求直接是打到我们的 Nginx 的 resources 的目录，现在将 resources 的地址重定向到阿里云的 CDN 内容分发网络，在获取静态资源内容先通过 CDN，CDN 没有在回源到阿里云源站（源站可以理解为本地静态资源文件），一边返回静态资源文件一边缓存起来，以便用户下一次访问时可以不做回源的操作

分布式会话持久性管理当一个用户通过前端访问时， Nginx 通过反向代理负载均衡的轮询策略转发打到 tomacat 中的 java 上，再这样的分布式会话中，原本 cookie + session 的方案在 tomcat 的内存级别维护 session 的列表显然就失效了，tomcat 之间的内存并不是互通的，这时就需要引入分布式会话管理存储会话有效期不与服务端发生交互的呆滞时间，Tomcat默认为30m会话续命：当用户在呆滞时间内又带着 cookieId 的请求过来，tomcat 会寻找到对应

验证码生成与验证技术包装秒杀令牌前置,需要验证码来错峰数学公式验证码生成器//生成验证码 @RequestMapping(value = "/generateverifycode",method = {RequestMethod.GET,RequestMethod.POST}) @ResponseBody public void generateverifycode(HttpServletResponse response) throws BusinessException,

为什么会存在流量削峰？主要是包含两个方面的能力，在之前经历了查询优化技术、交易优化技术使用了缓存校验 + 异步扣减库存的方式使得秒杀下单的性能有了明显提升。但是，再这样的一些技术当中，仍然不得不面临一些问题，也就是浪涌洪峰流量的涌入问题，秒杀瞬间的流量很大，我么需要将涌入的巨大流量平滑的过渡掉。因此，流量削峰技术应运而生目标掌握秒杀令牌的原理和使用方式掌握秒杀大闸的原理和使用方式掌握队列泄洪的原理和使用方式目前秒杀系统的缺陷秒杀下单接口会被脚本不停的刷新：秒杀的下单接口就是一个公网的

交易性能瓶颈交易验证完全依赖数据库 @Override @Transactional public OrderModel createOrder(Integer userId, Integer itemId, Integer promoId, Integer amount) throws BusinessException { //1.校验下单状态,下单的商品是否存在，用户是否合法，购买数量是否正确 ItemModel itemModel = i

多级缓存redis缓存默认springboot自带redisTemplet不带序列化热点内存本地缓存nginx proxy cache缓存nginx lua缓存

nginx反向代理负载均衡单机容量问题,水平扩展表象:单机cpu使用率增高，memory占用增加，网络带宽使用增加cpu us :用户空间的cpu使用情况(用户层代码)cpu sy :内核空间的cpu使用情况(系统调用)load average : 1,5,15分钟load平均值,跟着核数系数, 0代表通常 1代表打满1+代表等待阻塞memory:free空闲内存, used使用内存nginx反向代理makemake install动静分离负载

项目云端部署JDK 安装默认安装在 /usr/java 中刷新环境变量MySQL 安装备份、上传、恢复用maven打成jar包上传到服务器命令行输入：mvn clean packagepom 文件添加后刷新maven上传到服务器执行 java -jar 命令，访问不出来，去阿里云开放端口外挂配置文件编写 deploy 脚本jmeter性能压测线程组Http请求查看结果树聚合报告发现并发容量问题top -h先压200再5

CountDownLatchCountDownLatch(int count)：仅有一个构造函数，参数 count 为需要倒数的数值。await()：调用 await() 方法的线程会被挂起，它会等待直到 count值为 0 才继续执行。countDown()：将 count 值减1，直到为 0 时，等待的线程会被唤起。用法一一个线程等待多个线程都执行完毕再继续自己的工作。/** * 描述：工厂中，质检，5个工人检查，所有人都认为通过，才通过 */public class CountD.

应用场景乐观锁并发容器原子类Unsafe 类Unsafe 是 CAS 的核心类。Java 无法直接访问底层操作系统，而是通过本地 (native) 方法来访问。不过尽管如此，JVM 还是开了一个后门，JDK 中有一个类 Unsafe，它提供了硬件级别的原子操作valueOffset 表示的是变量值在内存中的偏移地址，因为 Unsafe 就是根据内存偏移地址获取数据的原值的，这样我们就能通过 unsafe 来实现 CAS 了文字描述我认为 V 的值应该是 A，如果是的话那我就把它改成 B，如

简单介绍CopyOnWriteArrayList 用来代替 Vector 和 SynchronizedList，就和 ConcurrentHashMap 代替 SynchronizedMap 的原因一样Vector 和 SynchronizedList 的锁的粒度太大，并发效率相对比较低，并且迭代时无法编辑Copy-On-Write 并发容器还包括 CopyOnWriteArraySet，用来替代同步 Set适用场景读操作可以尽可能地快，而写即使慢一些也没有太大关系读写规则回顾读写锁：读读共享

为什么HashMap是线程不安全的?同时put碰撞导致数据丢失同时put扩容导致数据丢失死循环造成的CPU100%

使用场景典型场景一每个线程需要一个独享的对象 (通常是工具类，典型需要使用的类有 SimpleDateFormat 和 Random)1000 个打印线程的任务，都用线程池来运行避免众多对象创建和销毁的开销，把 SimpleDateFormat 提出来作为公共变量，但这就会产生线程安全问题，解决方案可以加锁，但是太影响性能了，更好的解决方案使用 ThreadLocal，每个 Thread 内有自己的实例副本不共享，利用 ThreadLocal，给每个线程分配自己的 dateFormat 对象，保证

线程池的自我介绍如果不使用线程池，每个任务都新开一个线程处理◆ 一个线程◆ for 循环创建线程◆ 当任务数量上升到 1000这样开销太大，我们希望有固定数量的线程，来执行这 1000 个线程，这样就避免了反复创建并销毁线程所带来的开销问题。线程池的好处加快响应速度合理利用CPU和内存统一管理线程池适合应用的场合服务器接受到大量请求时,使用线程池技术是非常合适的,它可以大大减少线程的创建和销毁次数,提高服务器的工作效率实际上,在开发中,如果需要创建5个以上的线程,那么就可以使用线程池来