Runnable接口和Callable接口的区别

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的
第三部分进行比对如果比对成功就是验签成功，你就是我系统的正确令牌
如果在这个过程中有用户拦截了我们的请求，无论是把一改了还是把二改了还是把三改了
最后咱们使用