java技术汇总
2023-06-02 15:06:59 1 举报AI智能生成
登录查看完整内容
java技术栈汇总
作者其他创作
大纲/内容
索引分类
索引的数据结构
索引失效的场景
索引
事务
隔离级别
锁
数据库优化策略
数据恢复
mysql
关系型数据库
数据类型
持久化
过期键的删除策略
内存相关
线程模型
集群方案
分区
分布式
缓存异常
常用工具
redis
Elasticsearch支持实时GET请求，适合作为NoSQL数据存储，但缺少分布式事务
Elasticsearch
非关系型数据库
3.数据库
rocketMq
消息队列MQ
4.中间件
http协议
学习链接：https://blog.csdn.net/qq_45901741/article/details/119223513
https协议
又叫密钥加密，加解密只有一把钥匙
对称加密
https协议中，客户端将生成的对称密钥，用服务器给的公钥加密，服务器拿到密钥后，用私钥解密
公钥加密、私钥解密
CA证书，CA证书的签名由CA机构的私钥加密而来，但在使用中，浏览器使用CA机构的公钥进行解密
公钥解密、私钥加密
非对称加密
加密
5.网络安全
集合
jvm的内存配置和线程的关系
java中创建线程的方式
线程进入等待状态直到notify唤醒或者notifyAll唤醒
await
线程进入睡眠，该线程暂停
sleep
唤醒wait队列中的第一个线程，与此对应的notifyAll唤醒wait队列中的所有线程
notify
线程会让出资源，但是并不会让出锁，如果是加锁的代码块，会在该线程完全结束后其他线程才能访问
yield
主线程等待子线程执行完成后才继续执行。比如线程1在运行时join了线程2，那么线程1就会等待线程2执行结束时在执行
join
sleep()方法是属于Thread类中的。而wait()方法，则是属于Object类中的
sleep()方法导致了线程暂停执行指定的时间，让出cpu给其他线程
sleep()方法并不释放锁，只是会让出cpu
wait()方法会释放掉锁，让出系统资源；需要调用notify、notifyAll对其进行唤醒
await和sleep的区别
线程的几个重要方法
多线程基础
线程在有任务的时候会创建核心的线程数corePoolSize
当线程满了（有任务但是线程被使用完）不会立即扩容，而是放到阻塞队列中，当阻塞队列满了之后才会继续创建线程
如果队列满了，线程数达到最大线程数则会执行拒绝策略
当线程数大于核心线程数事，超过KeepAliveTime(闲置时间)，线程会被回收，最终会保持corePoolSize个线程
线程池的原理
核心线程数
DelayQueue
DelayedWorkQueue
有界队列，默认需要提供最大容量
ArrayBlockingQueue
上限是 Integer.MAX_VALUE，约为 2 的 31 次方，是非常大的一个数，可以近似认为是无限容量，因为我们几乎无法把这个容量装满
LinkedBlockingDeque
LinkedBlockingQueue
LinkedTransferQueue
PriorityBlockingQueue
SynchronousQueue
BlockingQueue
队列都是原子的，同步阻塞的，线程安全的，也即当一个线程在操作队列时，其他的需要等待
阻塞队列
核心线程和阻塞队列都满了的情况下，启动最大线程数
最大线程数
最大线程存活时间
线程工厂，ThreadFactory
拒绝策略
线程池的配置
入参：Runable
返回值：future
熟悉future的话，就知道线程池提交的都是实现了runnable的类，futureTask也是如此
submit
顶层接口 ExecutorService
常见的线程池
线程池
主内存：线程共享
本地内存：线程私有
JMM将计算机内存抽象为多级缓存，是一个抽象概念，并不是实际物理内存模型
CPU在执行指令的时候，从本地内存读取数据并操作
线程在执行时，将变量从主存加载到本地缓存
JMM内存模型
重量级锁，当线程遇到抢夺资源的情况下，如果未获得资源，CPU会将线程挂起，已获得资源的线程在结束之后，会掉notify方法唤醒其他线程
轻量级锁在遇到抢夺资源时，并不是将线程交给OS挂起，而是内部自旋，等待资源，当自旋次数过多，会升级为重量级锁
当抢夺资源非常频繁时，使用重量级锁，比较合理
重量级锁
无锁
偏向锁
while循环实现自旋，尝试从主存获取资源，synchronized自旋锁循环次数过多，会升级到重量级锁
自旋锁
轻量级锁
学习链接：https://www.cnblogs.com/yufeng218/p/13028549.html
synchronized关键字
使用JMM内存模型
被volatile修饰的变量禁止指令重排，被线程修改后，立马更新到主存，同时，其他线程对此变量的缓存失效，满足了可见性
但是volatile无法保证线程的原子性，比如多个线程同时从主存中拿到volatile变量，做修改后再更新到主存，在回写到主从的过程中，主存数据被修改，此时虽然线程缓存数据失效了，但是写操作依然进行，此时就会出现线程安全问题
解释一下写操作无法中断的原因：JMM内存模型规范里对主存的操作有：lock、unlock、read、load、use、assign、store、write，store指令将缓存数据送入主存，write指令将store的数据写入到主存，如果线程在store之后，write之前发现volatile变量值发生变化，则会出现线程安全问题
volatile虽然满足了可见性，但并不是原子性的，所以要在并发情况下使用，还必须满足原子性，CAS解决了这一问题
https://wenku.baidu.com/view/3475c056f142336c1eb91a37f111f18583d00cd3.html
volatile关键字
CAS的ABA问题
CAS（compare and swap）比较和交换
CAS操作的关键是在最后一步更新主存时，不是直接更新，而是对比后再更新，如果发现主存的值和缓存中的不相等，则进入自旋锁的状态，也就是循环重新尝试获取值再计算
CAS机制
CAS底层原理其实就是使用了volatile关键字实现
乐观锁
悲观锁
锁机制
原子操作类：atomic
可重入的互斥锁
具有与synchronized相同功能，但比synchronized更灵活
AQS里边维护了一个Node，https://blog.csdn.net/qq_43141726/article/details/121562620
AQS定义两种资源共享方式：Exclusive（独占，只有一个线程能执行，如ReentrantLock）和Share（共享，多个线程可同时执行，如Semaphore/CountDownLatch）
Node是一个双向链表
底层基于AbstractQueuedSynchronizer（同步队列AQS）+ CAS实现，关键还是用到volatile关键字
ReentrantLock 重入锁 一个持有锁的线程，在释放锁之前。此线程如果再次访问了该同步锁的其他的方法，这个线程不需要再次竞争锁，只需要记录重入次数。重入锁的设计目的是为了解决死锁的问题
学习链接：https://baijiahao.baidu.com/s?id=1702822534980452383&wfr=spider&for=pc
学习链接：https://blog.csdn.net/qq_34222160/article/details/123833283
给当前类创建一把锁管理器
锁管理器里边记录了调用当前类的线程，哪些在执行，哪些在阻塞
1. 创建锁 ReentrantLock reentrantLock = new ReentrantLock(true);
从当前类的锁管理器里边获取一把锁
获取成功则锁管理器里记录当前持有锁的线程
其它线程获取锁时，管理器需要等到当前锁被用完才能借给新线程
获取成功则处理业务
获取失败则不处理
3. 根据获取结果处理业务
主动释放锁，将锁权限还给锁管理器，告诉他我用完了，别人可以用锁了
4. 释放锁
使用实战
ReentrantLock
ReentrantReadWriteLock的内部public static类
ReadLock
ReentrantReadWriteLock的内部public static类
WriteLock
StampedLock下的内部类
ReadLockView
WriteLockView
ConcurrentHashMap的静态内部类，继承ReentrantLock
Segment
Lock
ReentrantReadWriteLock
ReadWriteLockView
ReadWriteLock
Lock锁：locks
并发包current
并发编程
多线程
IO流
内存分类
垃圾回收机制
常用命令
重要参数：https://blog.csdn.net/qq_16397653/article/details/120110768
学习资料：http://www.wjhsh.net/SummerinShire-p-5275863.html
调优
JVM
1.java基础
动态代理
切面的使用方式
Spring
SpringBoot终于受不了这种滥用，默认把循环依赖给禁用了！从2.6版本开始，如果你的项目里还存在循环依赖，SpringBoot将拒绝启动
SpringBoot
SpringMVC
Spring家族框架
Mybatis
MybatisPlus
数据库框架
2.框架技术
java技术汇总
收藏
收藏
0 条评论
回复 删除
下一页
