1.Callable接口有返回值,Runnable接口没有返回值。
2.Callable接口call()方法抛异常,Runnable接口run()方法不抛异常
3.Callable接口实现方法是call()方法,Runnable接口实现方法是run()方法。
只能接受Runnable,需要找一个中介FutureTask,而FutureTask的构造方法可以接受一个Callable接口,就把
Thread的接收类型Runnable接口和Callable接口联系在了一起
ReentrantReadWriteLock读写锁
按照世界观来分:1.乐观锁2.悲观锁
悲观锁:总有刁民想害朕,世界上全是坏人,就算是读数据也要加锁
只有我的读写操作完成了别人才能操作。
乐观锁:世界上还是好人多。读数据的时候不上锁,有个版本号的概念
一堆线程请求数据,只有第一个进入的线程可以修改成功,修改完以后增加版本号。
别的线程想要修改需要对比一下版本号,发现版本号已经是旧版本了,直接修改失败。
表锁和行锁的区别
表锁:就算读一行数据也要锁整张表。
行锁:操作哪一行就给哪一行加锁,其他行可以随便用。
行锁会出现死锁,表锁不会(因为锁的范围太大了)。
redis的list结构
从左边塞,从右边取 队列结构
从左边塞,从左边取 栈结构
线程池的七大参数:
核心线程数是懒加载,在new线程池的时候不指定
只有执行了execute()方法才会指定
给前后端分离的系统或者跨系统之间进行以JOSN的方式建立一个令牌,以JSON形式作为
Web应用中的令牌,用于在各方之间安全的将信息以JSON对象的形式传递,在数据传递过程
中还可以进行数据的加密、签名等相关处理。
在跨系统之间交互的时候会涉及到数据的传递
举个简单的例子:前端的系统怎么能访问后端系统的接口
每次访问的时候可以都会使用JWT去传递一个令牌
如果这个令牌是后端系统可以放行的令牌我就允许你访问
如果你不是我信任的令牌或者你没有携带令牌,不好意思,我拒绝你访问
第一个场景:作为JavaWeb中的一个令牌
前后端分离项目中,如果后端系统接口要求前端系统访问时必须携带令牌的
话,就可以使用JWT带上你的令牌,如果你的令牌验证通过,你就可以访问
如果你没有令牌或者令牌信息被篡改了,不好意思拒绝访问
第二个场景:他可以在系统之间因为这种令牌机制可以在系统之间进行数据传递
比如A系统向B系统传递数据,传递的时候我同样可以使用JWT来传递数据,而且在
整个数据传递的过程中我还可以对我的数据进行签名进行加密,我拿到之后我看看
中间是不是有人把我的数据篡改了,我拿到的数据是否是系统给我发的原数据我可
以在这边做一个签名校验也就是验签的一个过程
你在这边使用一个签名的钥匙给我签了,签了之后你把这个给我,我拿这个去解签
解完之后如果发现咱俩的数据能够对上,认为这次数据没有被篡改是安全的,我就可以继续
用这个信息,如果我发现你给我传的信息有问题了,那不好意思,我就直接不处理了,拒绝
其实JWT的核心作用有两点:一种可以用来做信息交换一种可以用来做JavaWeb里的安全
验证 用的比较多的是第一种安全验证
因为jwt可以进行跨域
jwt的认证方式完全是基于令牌的 而且是基于客户端的令牌存储
这个令牌是不存储在服务端的
使用JWT首先就解决了session内存占用的问题
认证还是由服务端认证 但是存储不由服务端存储
jwt令牌里面包含的东西非常非常的丰富要比我们原来session包含的还要丰富
jwt占用客户端的字节非常小他不会占用特别多的带宽
服务端拿到之后还可以从jwt中取出用户的相关信息不需要每次都从session中拿
节省了内存的占用也避免了日后后端做集群部署时我还要解决session问题
因为咱们现在的令牌都是基于浏览器端的也就是基于客户端的管理
头 负载 签名 都是json对象 {}.{}.{}
签名=头+负载+随机盐(也叫签名(永远不能给别人的。只有你自己知道)),你要把这个东西
给别人那你的加密就没有任何意义了,这就相当于你的一把钥匙,日后你全凭这把钥匙验证
你信息的合法性
接受到客户端jwt后会先进行验签 把jwt头部和荷载加上我的签名生成的字符串和jwt的
第三部分进行比对如果比对成功就是验签成功,你就是我系统的正确令牌
如果在这个过程中有用户拦截了我们的请求,无论是把一改了还是把二改了还是把三改了
最后咱们使用