读书笔记（三）

B站

1.redis的hash数据结构是如何实现的？

/* hash表是空的需要初始化空间, 默认是4*/

​ if (d->ht[0].size == 0) return dictExpand(d, DICT_HT_INITIAL_SIZE);

2.kafka中zookeeper的作用？

监控kafka broker节点和消费者节点，存储元信息

3.hashmap默认数组为空，初始化容量大小为16。

4.redis中单线程为什么要有事务？如果需要rehash，key很多，如何处理？

一般情况，rehash会由新设置key的时候触发开始。

但是因为redis是单线程，所以如果K很多时，不可能一步完成整个rehash操作，所以需要渐进式rehash。

分为两种：

1）操作redis时，额外做一步rehash

对redis做读取、插入、删除等操作时，会额外把位于table[dict->rehashidx]位置的链表移动到新的dictht中，然后把rehashidx做加一操作，移动到后面一个槽位。

2）后台定时任务调用rehash

后台定时任务rehash调用链

serverCron() - databasesCron() - incrementallyRehash() - dictRehashMilliseconds() - dictRehash()

控制rehash调用频率：每秒钟调用10次serverCron()方法，由server.hz配置。

笔记

String subString用法

public String substring(int beginIndex, int endIndex)

第一个int为开始的索引，对应String数字中的开始位置，

第二个是截止的索引位置，对应String中的结束位置

1、取得的字符串长度为：endIndex - beginIndex;

2、从beginIndex开始取，到endIndex结束，从0开始数，其中不包括endIndex位置的字符

如：

“hamburger”.substring(4, 8) returns “urge”

“smiles”.substring(1, 5) returns “mile”

取长度大于等于3的字符串a的后三个子字符串，只需a.subString(a.length()-3, a.length());

百度

zookeeper一致性协议是什么？

zookeeper：Zookeeper是一个分布式协调服务，可用于服务发现，分布式锁，分布式领导选举，配置管理等。

Zookeeper集群是一个基于主从复制的高可用集群，每个服务器承担如下三种角色中的一种

• Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
• Follower 一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。
• Observer 角色与Follower类似，但是无投票权。

参考链接：http://www.cnblogs.com/leesf456/p/6107600.html

http://www.jasongj.com/zookeeper/fastleaderelection/

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

(1) 服务器初始化启动。

(2) 服务器运行期间无法和Leader保持连接。

下面就两种情况进行分析讲解。

1. 服务器启动时期的Leader选举【FastLeaderElection】

若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

(1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID)来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下

· 优先检查ZXID。ZXID比较大的服务器优先作为Leader。

· 如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。
　　
　　由上面规则可知，通常那台服务器上的数据越新（ZXID会越大），其成为Leader的可能性越大，也就越能够保证数据的恢复。如果ZXID相同，则SID越大机会越大。

服务器状态

服务器具有四种状态，分别是LOOKING、FOLLOWING、LEADING、OBSERVING。

LOOKING：寻找Leader状态。当服务器处于该状态时，它会认为当前集群中没有Leader，因此需要进入Leader选举状态。

FOLLOWING：跟随者状态。表明当前服务器角色是Follower。

LEADING：领导者状态。表明当前服务器角色是Leader。

OBSERVING：观察者状态。表明当前服务器角色是Observer。

建立连接方式

为了能够相互投票，Zookeeper集群中的所有机器都需要两两建立起网络连接。QuorumCnxManager在启动时会创建一个ServerSocket来监听Leader选举的通信端口(默认为3888)。开启监听后，Zookeeper能够不断地接收到来自其他服务器的创建连接请求，在接收到其他服务器的TCP连接请求时，会进行处理。**为了避免两台机器之间重复地创建TCP连接，Zookeeper只允许SID大的服务器主动和其他机器建立连接，否则断开连接。**在接收到创建连接请求后，服务器通过对比自己和远程服务器的SID值来判断是否接收连接请求，如果当前服务器发现自己的SID更大，那么会断开当前连接，然后自己主动和远程服务器建立连接。一旦连接建立，就会根据远程服务器的SID来创建相应的消息发送器SendWorker和消息接收器RecvWorker，并启动。

zookeeper原理、概念、应用场景

参考链接：https://blog.youkuaiyun.com/wzk646795873/article/details/79706627

zookeeper维护一个类似文件系统的数据结构。

用途：1.配置管理：配置放置在某个节点，其他相关应用程序会监听这个节点，一旦配置信息发生变化，相关应用程序就会收到通知。

2.集群管理：所有机器在父目录GroupMember下创建临时目录节点，然后监听父目录下子节点的变化。机器挂掉，临时目录节点被删除，其他机器收到通知。Master选取：所有机器创建临时顺序编号目录节点，选取编号最小的为master。

3.分布式锁：一个znode作为一把锁，创建成功获得锁，用完删除释放锁。【或者取最小编号】

多个partition 一个consumer，会不会只消费一个partition？

如果分配的partition没有消费完，会只消费这个分区。

消费组中的消费者会怎么取kafka的数据呢？
其实kafka的消费端有一个均衡算法，算法如下：

1.A=(partition数量/同分组消费者总个数)
2.M=对上面所得到的A值小数点第一位向上取整
3.计算出该消费者拉取数据的patition合集：Ci = [P(M*i ),P((i + 1) * M -1)]

按照如图所示，那么这里：

A=6/8=0.75

M=1

C0=[P(1*0),P((0+1)*1-1)]=[P0,P0]

总结：

1.按照如上的算法，所以如果kafka的消费组需要增加组员，最多增加到和partition数量一致，超过的组员只会占用资源，而不起作用；

2.kafka的partition的个数一定要大于消费组组员的个数，并且partition的个数对于消费组组员取模一定要为0，不然有些消费者会占用资源却不起作用；

3.如果需要增加消费组的组员个数，那么也需要根据上面的算法，调整partition的个数

Kafka消费保证顺序

数据只分配到一个partition

多个线程没有返回值，如何保证同步性？

countdownlatch

CountDownLatch是一个同步工具类，它允许一个或多个线程一直等待，直到其他线程的操作执行完后再执行。

参考链接：http://www.importnew.com/15731.html

CountDownLatch是通过一个计数器来实现的，计数器的初始值为线程的数量。每当一个线程完成了自己的任务后，计数器的值就会减1。当计数器值到达0时，它表示所有的线程已经完成了任务，然后在闭锁上等待的线程就可以恢复执行任务。

构造器中的计数值（count）实际上就是闭锁需要等待的线程数量。这个值只能被设置一次，而且CountDownLatch没有提供任何机制去重新设置这个计数值。

与CountDownLatch的第一次交互是主线程等待其他线程。主线程必须在启动其他线程后立即调用**CountDownLatch.await()**方法。这样主线程的操作就会在这个方法上阻塞，直到其他线程完成各自的任务。

其他N 个线程必须引用闭锁对象，因为他们需要通知CountDownLatch对象，他们已经完成了各自的任务。这种通知机制是通过 **CountDownLatch.countDown()**方法来完成的；每调用一次这个方法，在构造函数中初始化的count值就减1。所以当N个线程都调 用了这个方法，count的值等于0，然后主线程就能通过await()方法，恢复执行自己的任务。

读写锁

参考链接：https://www.cnblogs.com/wait-pigblog/p/9350569.html

读写锁是一种特殊的自旋锁，它把对共享资源对访问者划分成了读者和写者，读者只对共享资源进行访问，写者则是对共享资源进行写操作。读写锁在ReentrantLock上进行了拓展使得该锁更适合读操作远远大于写操作对场景。一个读写锁同时只能存在一个写锁但是可以存在多个读锁，但不能同时存在写锁和读锁。

ReentrantReadWriteLock的基本原理和ReentrantLock没有很大的区别，只不过在ReentantLock的基础上拓展了两个不同类型的锁，读锁和写锁。首先可以看一下ReentrantReadWriteLock的内部结构：

重入锁和非重入锁

所谓可重入，意味着线程可以进入它已经拥有的锁的同步代码块儿。

广义上的可重入锁指的是可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁（前提得是同一个对象或者class），这样的锁就叫做可重入锁。ReentrantLock和synchronized都是可重入锁。

不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生死锁。

参考：https://blog.youkuaiyun.com/rickiyeat/article/details/78314451

jdbcTemplate获取自增主键

KeyHolder keyHolder = new GeneratedKeyHolder();  
        int autoIncId = 0;  
        jdbcTemplate.update( sql, parameters, keyHolder); 
        autoIncId = keyHolder.getKey().intValue();  

springboot starter 如何封装的？

spring-boot-starter-web包自动帮我们引入了web模块开发需要的相关jar包，

mybatis-spring-boot-starter帮我们引入了dao开发相关的jar包。

spring-boot-starter-xxx是官方提供的starter，xxx-spring-boot-starter是第三方提供的starter。

可以看出在这个mybatis-spring-boot-starter 中，并没有任何源码，只有一个pom文件，它的作用就是帮我们引入了相关jar包。

@Configuration & @Bean这两个注解一起使用就可以创建一个基于java代码的配置类，可以用来替代相应的xml配置文件。

@Configuration注解的类可以看作是能生产让Spring IoC容器管理的Bean实例的工厂。

@Bean注解告诉Spring，一个带有@Bean的注解方法将返回一个对象，该对象应该被注册到spring容器中。

我们可以将自动配置的关键几步以及相应的注解总结如下：

1、@Configuration&与@Bean->基于java代码的bean配置

2、@Conditional->设置自动配置条件依赖

3、@EnableConfigurationProperties与@ConfigurationProperties->读取配置文件转换为bean。

4、@EnableAutoConfiguration、@AutoConfigurationPackage 与@Import->实现bean发现与加载。

参考链接：https://www.cnblogs.com/hjwublog/p/10332042.html

那么 SpringBoot 是如何知道要实例化哪些类，并进行自动配置的呢？ 下面简单说一下。

首先，SpringBoot 在启动时会去依赖的starter包中寻找 resources/META-INF/spring.factories文件，然后根据文件中配置的Jar包去扫描项目所依赖的Jar包，这类似于 Java 的 SPI 机制。

第二步，根据 spring.factories配置加载AutoConfigure类。

最后，根据 @Conditional注解的条件，进行自动配置并将Bean注入Spring Context 上下文当中。

我们也可以使用@ImportAutoConfiguration({MyServiceAutoConfiguration.class}) 指定自动配置哪些类。

编写自己的springboot-starter

参考链接：

https://www.jianshu.com/p/45538b44e04e

https://www.cnblogs.com/yuansc/p/9088212.html

阻塞队列

参考链接：https://www.cnblogs.com/tjudzj/p/4454490.html

@Bean生命周期 scope

默认是单例模式，即scope=“singleton”。另外scope还有prototype、request、session、global session作用域。scope="prototype"多例

@Conditional

spring加载自定义配置

事务配置@Transactional

工厂模式 反射方法

try catch resource

JDK 7 中的 try-with-resources 介绍

try-with-resources 是 JDK 7 中一个新的异常处理机制，它能够很容易地关闭在 try-catch 语句块中使用的资源。所谓的资源（resource）是指在程序完成后，必须关闭的对象。try-with-resources 语句确保了每个资源在语句结束时关闭。所有实现了 java.lang.AutoCloseable 接口（其中，它包括实现了 java.io.Closeable 的所有对象），可以使用作为资源。

例如，我们自定义一个资源类

public class Demo {    
    public static void main(String[] args) {
        try(Resource res = new Resource()) {
            res.doSome();
        } catch(Exception ex) {
            ex.printStackTrace();
        }
    }
}

class Resource implements AutoCloseable {
    void doSome() {
        System.out.println("do something");
    }
    @Override
    public void close() throws Exception {
        System.out.println("resource is closed");
    }
}
执行输出如下：

do something
resource is closed

可以看到，资源终止被自动关闭了。参考链接：http://www.importnew.com/21544.html

注意：如果有多个资源，在 try 语句中越是最后使用的资源，越是最早被关闭。

文件释放资源顺序，外层释放，内层会释放吗？

一般情况下是：先打开的后关闭，后打开的先关闭

另一种情况：看依赖关系，如果流a依赖流b，应该先关闭流a，再关闭流b

例如处理流a依赖节点流b，应该先关闭处理流a，再关闭节点流b

当然完全可以只关闭处理流，不用关闭节点流。处理流关闭的时候，会调用其处理的节点流的关闭方法

先看一段代码：
FileOutputStream out1 = new FileOutputStream(“D:\SingleTon.txt”);
ObjectOutputStream out2 = new ObjectOutputStream(out1);
out1.close();//是否需要关闭内层的IO流？
out2.close();
考虑一下，像这样的嵌套IO流，是否应该从内到外依次关闭呢?

答案是不需要！这些IO类都是JDK自带的，调用了最外层的close方法，其实是一层一层向内调用了最内层的IO类的close方法，这也就是装饰者模式。

当然你肯定想问，为什么我之前自内向外逐层关闭也不会抛出异常？

因为就算你对某个流重复关闭多次，也不会抛出异常。

java8新特性 函数式编程 lamda表达式

语法糖（Syntactic sugar），也译为糖衣语法，指计算机语言中添加的某种语法，这种语法对语言的功能没有影响，但是更方便程序员使用。语法糖让程序更加简洁，有更高的可读性。

lambda表达式允许你通过表达式来代替功能接口。 lambda表达式就和方法一样,它提供了一个正常的参数列表和一个使用这些参数的主体(body,可以是一个表达式或一个代码块)。

Lambda表达式的语法
基本语法:
(parameters) -> expression
或
(parameters) ->{ statements; }

使用Lambda的优缺点

使用Lambda表达式可以简化接口匿名内部类的使用，可以减少类文件的生成，可能是未来编程的一种趋势。但是使用Lambda表达式会减弱代码的可读性，而且Lambda表达式的使用局限性比较强，只能适用于接口只有一个抽象方法时使用，不宜调试。

Stream是对集合的包装,通常和lambda一起使用。 使用lambdas可以支持许多操作,如 map, filter, limit, sorted, count, min, max, sum, collect 等等。

phpProgrammers.stream()  
          .filter((p) -> (p.getSalary() > 1400))  
          .forEach((p) -> System.out.printf("%s %s; ", p.getFirstName(), p.getLastName()));  

lambda表达式和函数式编程

函数式编程用函数来表达所有的概念，完成所有的操作。面向对象编程中，把对象当作参数传递，而在函数式编程中，函数可以作为其他函数的参数传递，返回值也可以是函数。Lambda表达式实现了函数式编程。方法可以被当作参数传递到其他方法内，如同对象实例或数。

新特性——接口的默认方法（default）

接口的默认方法是为了解决接口演化问题，即新版本中对接口进行修改，会导致早期版本的代码无法运行。因为接口中的方法必须被实现，若在接口中添加新方法，可能进行大量重构。所以，若往一个接口中添加新的方法，可以提供该方法的默认实现。

有了默认方法，对已有的接口使用者来说，代码可以继续运行。新的代码可以继续使用该方法，也可以重写默认的实现。当我们定义了一个默认接口方法之后，所有实现该接口的子类都间接持有了该方法。

这个default方法的主要目的是为java8的Lambda表达式提供支持，比如在Iterable接口中新增了foreach默认方法。如果将这个方法定义为普通接口方法，则会对现有的JDK的其他使用Iterable接口的类造成影响，因此提供了default方法的功能。

shutdown Hook

参考链接：https://www.cnblogs.com/maxstack/p/9112711.html

webService和restful

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BcBYatgI-1577712358091)(d:\user\01376873\桌面\webService.jpg)]

REST是一种架构风格，其核心是面向资源；而webService底层SOAP协议，主要核心是面向活动；

webservice soap协议

restful HTTP协议

SOAP最早是针对RPC的一种解决方案，简单对象访问协议。可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。

SOAP webService有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。

Redis

redis主从复制原理

参考链接：https://www.cnblogs.com/kevingrace/p/5685332.html

Redis主从复制是如何工作的

如果设置了一个从服务器，在连接时它发送了一个SYNC命令，不管它是第一次连接还是再次连接都没有关系。然后主服务器开始后台存储，并且开始缓存新连接进来的修改数据的命令。当后台存储完成后，主服务器把数据文件发送到从服务器，从服务器将其保存在磁盘上，然后加载到内存中。然后主服务器把刚才缓存的命令发送到从服务器。这是作为命令流来完成的，并且和Redis协议本身格式相同。你可以通过telnet自己尝试一下。在Redis服务器工作时连接到Redis端口，发送SYNC命令，会看到一个批量的传输，并且主服务器接收的每一个命令都会通过telnet会话重新发送一遍。当主从服务器之间的连接由于某些原因断开时，从服务器可以自动进行重连接。当有多个从服务器同时请求同步时，主服务器只进行一个后台存储。当连接断开又重新连上之后，一般都会进行一个完整的重新同步，但是从Redis2.8开始，只重新同步一部分也可以。

Redis主从同步策略
主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

哨兵模式实现原理？（2.8版本或更高才有）

1.三个定时监控任务：

1.1 每隔10s，每个S节点（哨兵节点）会向主节点和从节点发送info命令获取最新的拓扑结构

1.2 每隔2s，每个S节点会向某频道上发送该S节点对于主节点的判断以及当前Sl节点的信息，

同时每个Sentinel节点也会订阅该频道，来了解其他S节点以及它们对主节点的判断（做客观下线依据）

1.3 每隔1s，每个S节点会向主节点、从节点、其余S节点发送一条ping命令做一次心跳检测(心跳检测机制)，来确认这些节点当前是否可达

2.主客观下线：

2.1主观下线：根据第三个定时任务对没有有效回复的节点做主观下线处理

2.2客观下线：若主观下线的是主节点，会咨询其他S节点对该主节点的判断，超过半数，对该主节点做客观下线

3.选举出某一哨兵节点作为领导者，来进行故障转移。选举方式：raft算法。每个S节点有一票同意权，哪个S节点做出主观下线的时候，就会询问其他S节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客观下线，谁成为领导者。

4.故障转移（选举新主节点流程）：

作者：java进阶架构师
来源：优快云
原文：https://blog.youkuaiyun.com/zlc3323/article/details/80836881
版权声明：本文为博主原创文章，转载请附上博文链接！

Kafka

在数据生产时避免数据丢失的方法：
只要能避免上述两种情况，那么就可以保证生产者消息不会被丢失。
1）就是说在同步模式的时候，确认机制设置为-1，也就是让消息写入leader和所有的副本。
2）还有，在异步模式下，如果消息发出去了，但还没有收到确认的时候，缓冲池满了，在配置文件中设置成不限制阻塞超时的时间，也就说让生产端一直阻塞，这样也能保证数据不会丢失。

数据丢失Consumer端

consumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset，那么就有可能造成数据的丢失。由于Kafka consumer默认是自动提交位移的，所以在后台提交位移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长，则建议把逻辑放到另一个线程中去做。为了避免数据丢失，现给出两点建议：

enable.auto.commit=false 关闭自动提交位移
在消息被完整处理之后再手动提交位移

在规定的时间（session.time.out默认30s）内没有消费完，就会可能导致re-blance重平衡，导致一部分offset自动提交失败，然后重平衡后重复消费（这种很常见）；或者关闭kafka时，如果在close之前，调用consumer.unsubscribe()则可能有部分offset没提交，下次重启会重复消费

数据重复消费的情况，如果处理？ reblance过程可能出现重复消费
（1）去重：将消息的唯一标识保存到外部介质中，每次消费处理时判断是否处理过；
（2）不管：大数据场景中，报表系统或者日志信息丢失几条都无所谓，不会影响最终的统计分析结果。

Hbase

https://www.cnblogs.com/steven-note/p/7209398.html

HRegion定位：HRegion被分配给哪个HRegionServer是完全动态的，所以需要机制来定位HRegion具体在哪个HRegionServer，HBase使用三层结构来定位HRegion：

​ 1、通过zk里的文件/hbase/rs得到-ROOT-表的位置。-ROOT-表只有一个region。

​ 2、通过-ROOT-表查找.META.表的第一个表中相应的HRegion位置。其实-ROOT-表是.META.表的第一个region；

​ .META.表中的每一个Region在-ROOT-表中都是一行记录。

​ 3、通过.META.表找到所要的用户表HRegion的位置。用户表的每个HRegion在.META.表中都是一行记录。

​ -ROOT-表永远不会被分隔为多个HRegion，保证了最多需要三次跳转，就能定位到任意的region。Client会将查询的位置信息保存缓存起来，缓存不会主动失效，

​ 因此如果Client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的HRegion，其中三次用来发现缓存失效，另外三次用来获取位置信息。

红黑树时间复杂度

红黑树的时间复杂度为O(logn)

hashSet,hashtable,hashMap 都是基于散列函数， 时间复杂度 O(1) 但是如果太差的话是O(n)

TreeSet==>O(log(n))==> 基于树的搜索，只需要搜索一半即可

采用二叉树作为存储结构，每个左节点均小于父节点，每个右节点均大于父节点

时间复杂度：O(log2(n))

前端传数字0，后端用Integer,mybatis如果判断！=“” 会出问题

redis分布式锁

dubbo底层原理

死锁

死锁产生的四个必要条件

互斥条件：资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。
不可剥夺条件：进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。
请求和保持条件：进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。
循环等待条件：在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路，环路中每一个进程所占有的资源同时被另一个申请，也就是前一个进程占有后一个进程所深情地资源。

轻量锁 重量锁 偏向锁

java中每个对象都可作为锁，锁有四种级别，按照量级从轻到重分为：无锁、偏向锁、轻量级锁、重量级锁。每个对象一开始都是无锁的，随着线程间争夺锁，越激烈，锁的级别越高，并且锁只能升级不能降级。

偏向锁

在实际应用运行过程中发现，“锁总是同一个线程持有，很少发生竞争”，也就是说锁总是被第一个占用他的线程拥有，这个线程就是锁的偏向线程。

轻量级锁

当有另一个线程来竞争锁的时候，就不能再使用偏向锁了，要膨胀为轻量级锁。

轻量锁与偏向锁不同的是：

轻量级锁每次退出同步块都需要释放锁，而偏向锁是在竞争发生时才释放锁每次进入退出同步块都需要CAS更新对象头，争夺轻量级锁失败时，自旋尝试抢占锁可以看到轻量锁适合在竞争情况下使用，其自旋锁可以保证响应速度快，但自旋操作会占用CPU，所以一些计算时间长的操作不适合使用轻量级锁。

重量级锁

当竞争线程尝试占用轻量级锁失败多次之后，轻量级锁就会膨胀为重量级锁，重量级线程指针指向竞争线程，竞争线程也会阻塞，等待轻量级线程释放锁后唤醒他。
重量级锁的加锁、解锁过程和轻量级锁差不多，区别是：竞争失败后，线程阻塞，释放锁后，唤醒阻塞的线程，不使用自旋锁，不会那么消耗CPU，所以重量级锁适合用在同步块执行时间长的情况下。

自旋锁

自旋锁（spinlock）：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。

获取锁的线程一直处于活跃状态，但是并没有执行任何有效的任务，使用这种锁会造成busy-waiting。

联合索引查找原理

b+树性质

1.通过上面的分析，我们知道IO次数取决于b+数的高度h，假设当前数据表的数据为N，每个磁盘块的数据项的数量是m，则有h=㏒(m+1)N，当数据量N一定的情况下，m越大，h越小；而m = 磁盘块的大小 / 数据项的大小，磁盘块的大小也就是一个数据页的大小，是固定的，如果数据项占的空间越小，数据项的数量越多，树的高度越低。这就是为什么每个数据项，即索引字段要尽量的小，比如int占4字节，要比bigint8字节少一半。这也是为什么b+树要求把真实的数据放到叶子节点而不是内层节点，一旦放到内层节点，磁盘块的数据项会大幅度下降，导致树增高。当数据项等于1时将会退化成线性表。

2.当b+树的数据项是复合的数据结构，比如(name,age,sex)的时候，b+数是按照从左到右的顺序来建立搜索树的，比如当(张三,20,F)这样的数据来检索的时候，b+树会优先比较name来确定下一步的所搜方向，如果name相同再依次比较age和sex，最后得到检索的数据；但当(20,F)这样的没有name的数据来的时候，b+树就不知道下一步该查哪个节点，因为建立搜索树的时候name就是第一个比较因子，必须要先根据name来搜索才能知道下一步去哪里查询。比如当(张三,F)这样的数据来检索时，b+树可以用name来指定搜索方向，但下一个字段age的缺失，所以只能把名字等于张三的数据都找到，然后再匹配性别是F的数据了， 这个是非常重要的性质，即索引的最左匹配特性。

联合索引的非叶子节点是多列索引构成的。

建立索引原则

1.最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

2.=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式

3.尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录

4.索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);

5.尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可

如何定位慢SQL

连接远程MySQL
mysql -ubrms -p5s5cHf4cIC -hbrms-m.dbsit.sfdc.com.cn -P3306 -Dbrms

慢SQL查询：

1.慢查询时间 show variables like 'long_query_time';
2.修改慢查询：set long_query_time=1;  意思 查询时间超过1秒，为被视为慢查询，（但改修改方法会在mysql重启后恢复默认值）
3.慢查询数量
show status like "%slow_queries%"
4.mysql 默认情况下是不会记录慢查询的，需要启动时指定慢查询记录到log里才行
修改my.cnf
slow_query_log =on（默认为off）
slow_query_log_file=/usr/local/mysql/data/localhost-slow.log (系统默认给的日志文件)

查询是否开启了慢查询日志
mysql> show variables like ‘%slow%’;
如果slow_query_log 为 off，则
mysql> set global slow_query_log=1;

在mysql的my.ini中，查找datadir
datadir=E:/wamp/bin/mysql/mysql5.5.24/data
在data目录下，会生成一个log日志，里面即可定位慢查询的sql语句！

生产定位问题的工具

Jersy 和 restful

Java EE6引入了JAX-RS(Java API for RESTful Web Services)-JSR331。RESTful Service由于轻量，好测试，有弹性等特点，越来越受欢迎。Jersey，RESTEasy都是JAX-RS标准的具体实现。
RESTEasy(JBoss), Jersey(Sun提供的参考实现)
还有一种spring framework(spring/springMVC)的restful支持

如何实现序列化

Hbase列族有哪些字段？版本号？

Hbase基础

参考链接：https://blog.youkuaiyun.com/qq_31780525/article/details/53415251

Hbase背景：Hadoop可以很好地解决大规模数据的离线批量处理问题，但是，受限于HadoopMapReduce编程框架的高延迟数据处理机制，使得Hadoop无法满足大规模数据实时处理应用的需求，HBase已经成功应用于互联网服务领域和传统行业的众多在线式数据分析处理系统中。

**数据维护：**在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留。【时间戳来区分不同版本】

1、HBase的实现包括三个主要的功能组件：

（1）库函数：链接到每个客户端
（2）一个Master主服务器
（3）许多个Region服务器

主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡

Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求

客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据

客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小

2、Region

开始只有一个Region，后来不断分裂

Region拆分操作非常快，接近瞬间，因为拆分之后的Region读取的仍然是原存储文件，直到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件

同一个Region不会被分拆到多个Region服务器

每个Region服务器存储10-1000个Region

3.Hbase三级寻址

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7l0cJGu2-1577712358105)(https://i.imgur.com/qEDDiHI.png)]

4.Hbase容错

分布式环境必须要考虑系统出错。HBase采用HLog保证系统恢复
HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（WriteAhead Log）
用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。

Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master
Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录
系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器
Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复

共用日志优点：提高对表的写操作性能；缺点：恢复时需要分拆日志

Max Version：创建表的时候，可以通过HColumnDescriptor.setMaxVersions(int maxVersions)设置表中数据的最大版本，如果只需要保存最新版本的数据，那么可以设置setMaxVersions(1)。

5.HbaseTemplate
Spring封装的HbaseTemplate工具类

JPA

前后端分离 cors jsonp nignx反向代理

为了防范跨域攻击，所有现代浏览器都遵循一套同源策略。这里需要注意的是：同源不仅仅要求相同的域名或ip，连协议和端口也必须相同。
CORS 全称是跨域资源共享（Cross-Origin Resource Sharing），是一种 AJAX 跨域请求资源的方式，支持现代浏览器，IE支持10以上。
CORS与JSONP的使用目的相同，但是比JSONP更强大。JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

作者：柏龙
链接：https://www.jianshu.com/p/e79024ba9cc7
来源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

redis与数据库保持一致性

参考链接：https://blog.youkuaiyun.com/qq_27384769/article/details/79499373

一般的策略是当更新数据时，先删除缓存数据，然后更新数据库，而不是更新缓存，等要查询的时候才把最新的数据更新到缓存

补充：

写完数据库后是否需要马上更新缓存还是直接删除缓存？
（1）、如果写数据库的值与更新到缓存值是一样的，不需要经过任何的计算，可以马上更新缓存，但是如果对于那种写数据频繁而读数据少的场景并不合适这种解决方案，因为也许还没有查询就被删除或修改了，这样会浪费时间和资源
（2）、如果写数据库的值与更新缓存的值不一致，写入缓存中的数据需要经过几个表的关联计算后得到的结果插入缓存中，那就没有必要马上更新缓存，只有删除缓存即可，等到查询的时候在去把计算后得到的结果插入到缓存中即可。

在高并发的情况下，如果当删除完缓存的时候，这时去更新数据库，但还没有更新完，另外一个请求来查询数据，发现缓存里没有，就去数据库里查，还是以上面商品库存为例，如果数据库中产品的库存是100，那么查询到的库存是100，然后插入缓存，插入完缓存后，原来那个更新数据库的线程把数据库更新为了99，导致数据库与缓存不一致的情况

遇到这种情况，可以用队列的去解决这个问，创建几个队列，如20个，根据商品的ID去做hash值，然后对队列个数取摸，当有数据更新请求时，先把它丢到队列里去，当更新完后在从队列里去除，如果在更新的过程中，遇到以上场景，先去缓存里看下有没有数据，如果没有，可以先去队列里看是否有相同商品ID在做更新，如果有也把查询的请求发送到队列里去，然后同步等待缓存更新完成。

Redis相比memcached有哪些优势？

(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis的速度比memcached快很多

(3) redis可以持久化其数据

参考链接：http://blog.itpub.net/31545684/viewspace-2213990/

Redis有哪几种数据淘汰策略？

noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）

allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。

volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。

allkeys-random: 回收随机的键使得新添加的数据有空间存放。

volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。

volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。

MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据？

redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

Redis支持的Java客户端都有哪些？官方推荐用哪个？

Redisson、Jedis、lettuce等等，官方推荐使用Redisson。

说说Redis哈希槽的概念？

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

Redis如何做内存优化？

尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。

比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。

Redis回收进程如何工作的？

Redi检查内存使用情况，如果大于maxmemory的限制, 则根据设定好的策略进行回收。

@RequestParam详解以及加与不加的区别

1.@RequestParam Long parentId 2. Long parentId
第一种URL中必须有parentId，第二种可以有也可以没有；如果第一种required=false则和第二种一样
default设置默认值
value=“id” 则URL参数中为id才能接受到参数

T t = clazz.newInstance();失败

背景知识：如果定义了一个有参数的构造函数，无参数的默认构造函数会失效，要想继续使用无参数的构造函数，必须使用重载重新定义一个无参数的构造函数

public T newInstance()
              throws InstantiationException,
                     IllegalAccessException

注意，此方法传播 null 构造方法所抛出的任何异常，包括已检查的异常。使用此方法可以有效地绕过编译时的异常检查，而在其他情况下编译器都会执行该检查。 Constructor.newInstance 方法将该构造方法所抛出的任何异常包装在一个（已检查的）InvocationTargetException 中，从而避免了这一问题。

返回：
此对象所表示的类的一个新分配的实例。
抛出：
IllegalAccessException - 如果该类或其 null 构造方法是不可访问的。
InstantiationException - 如果此 Class 表示一个抽象类、接口、数组类、基本类型或 void； 或者该类没有 null 构造方法； 或者由于其他某种原因导致实例化失败。

component-scan作用

通常情况下我们在创建spring项目的时候在xml配置文件中都会配置这个标签，配置完这个标签后，spring就会去自动扫描base-package对应的路径或者该路径的子包下面的java文件，如果扫描到文件中带有@Service,@Component,@Repository,@Controller等这些注解的类，则把这些类注册为bean

application.properties是如何加载读取的

mysql update 返回值

默认情况下，mybatis 的 update 操作返回值是记录的 matched 的条数，并不是影响的记录条数。
严格意义上来将，这并不是 mybatis 的返回值，mybatis 仅仅只是返回的数据库连接驱动（通常是 JDBC ）的返回值，也就是说，如果驱动告知更新 2 条记录受影响，那么我们将得到 mybatis 的返回值就会是 2 和 mybatis 本身是没有关系的。
道理我都懂，如果我们非得要 mybatis 的 update 操作明确的返回受影响的记录条数，有没有什么办法呢？
当然是有的。
通过对 JDBC URL 显式的指定 useAffectedRows 选项，我们将可以得到受影响的记录的条数：
jdbc:mysql://$jdbc.host/${jdbc.db}?useAffectedRows=true

mysql -ubrms -p5s5cHf4cIC -hbrms-m.dbsit.sfdc.com.cn -P3306 -Dbrms

慢SQL优化

慢SQL查询：
1.慢查询时间 show variables like ‘long_query_time’;
2.修改慢查询：set long_query_time=1; 意思 查询时间超过1秒，为被视为慢查询，（但改修改方法会在mysql重启后恢复默认值）
3.慢查询数量
show status like “%slow_queries%”
4.mysql 默认情况下是不会记录慢查询的，需要启动时指定慢查询记录到log里才行
修改my.cnf
slow_query_log =1（默认为off）
slow_query_log_file=/usr/local/mysql/data/localhost-slow.log (系统默认给的日志文件)

查询是否开启了慢查询日志
mysql> show variables like ‘%slow%’;
如果slow_query_log 为 off，则
mysql> set global slow_query_log=1;

在mysql的my.ini中，查找datadir
datadir=E:/wamp/bin/mysql/mysql5.5.24/data
在data目录下，会生成一个log日志，里面即可定位慢查询的sql语句！

git操作

git pull 和 git commit先后顺序； git stash 和 git unstash
我的建议是：

1.在本地修改与远程代码无冲突的情况下，优先使用：pull->commit->push

2.在本地修改与远程代码有冲突的情况下，优先使用：commit->pull->push

git fetch

git pull origin/master 相当于
git fetch origin master + $ git merge origin/master

$ git fetch
上面命令将某个远程主机的更新，全部取回本地。默认情况下，git fetch取回所有分支的更新。如果只想取回特定分支的更新，可以指定分支名,如下所示 -
$ git fetch <远程主机名> <分支名>
Shell
比如，取回origin主机的master分支。
$ git fetch origin master原文出自【易百教程】，商业转载请联系作者获得授权，非商业请保留原文链接：https://www.yiibai.com/git/git_fetch.html

$ git fetch

Shell
上面命令将某个远程主机的更新，全部取回本地。默认情况下，git fetch取回所有分支的更新。如果只想取回特定分支的更新，可以指定分支名,如下所示 -

$ git fetch <远程主机名> <分支名>
Shell
比如，取回origin主机的master分支。

$ git fetch origin master

git stash

参考链接：https://www.cnblogs.com/tocy/p/git-stash-reference.html

git stash后可以看到又回到了从代码库pull下来的最新状态 。

git stash 可用于以下情形：

发现有一个类是多余的，想删掉它又担心以后需要查看它的代码，想保存它但又不想增加一个脏的提交。这时就可以考虑git stash。

使用git的时候，我们往往使用分支（branch）解决任务切换问题，例如，我们往往会建一个自己的分支去修改和调试代码, 如果别人或者自己发现原有的分支上有个不得不修改的bug，我们往往会把完成一半的代码commit提交到本地仓库，然后切换分支去修改bug，改好之后再切换回来。这样的话往往log上会有大量不必要的记录。其实如果我们不想提交完成一半或者不完善的代码，但是却不得不去修改一个紧急Bug，那么使用git stash就可以将你当前未提交到本地（和服务器）的代码推入到Git的栈中，这时候你的工作区间和上一次提交的内容是完全一样的，所以你可以放心的修Bug，等到修完Bug，提交到服务器上后，再使用git stash apply将以前一半的工作应用回来。

经常有这样的事情发生，当你正在进行项目中某一部分的工作，里面的东西处于一个比较杂乱的状态，而你想转到其他分支上进行一些工作。问题是，你不想提交进行了一半的工作，否则以后你无法回到这个工作点。解决这个问题的办法就是git stash命令。储藏(stash)可以获取你工作目录的中间状态——也就是你修改过的被追踪的文件和暂存的变更——并将它保存到一个未完结变更的堆栈中，随时可以重新应用。

Git版本回退

首先，根据git提交的历史记录中确定回退的版本

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L1YDFG5m-1577712358111)(https://i.imgur.com/DUBGjOq.jpg)]
git–>log–>历史记录选中某个需要回退的版本–>右键–>copy Revision Number

将上述拷贝的Revision Number记录下来，如：4b91ea12de20cdf97eccb6bc9125bbc2fef79b17
备注：后面两步在idea中好似不能图形化操作界面，只能用命令行了

其次，恢复到指定的commit hash
git reset --hard resetVersionHash
eg:git reset --hard 4b91ea12de20cdf97eccb6bc9125bbc2fef79b17

最后，把当前分支强制提交到远程
git push -f origin currentBranch
eg: push -f origin master

以上三步操作后，就将本地和git远端的代码从2017-8-12 18:45回退到了2017-8-12 17:01。

常用快捷键

加粗：Ctrl+B

斜体：Ctrl+I

字体：Ctrl+数字

下划线：Ctrl+U

返回开头：Ctrl+Home

返回结尾：Ctrl+End

生成表格：Ctrl+T

创建链接：Ctrl+K

no resource found for POST return 405 with allow header

webank

基本数据类型

int float double boolean byte char long short

HTTP协议 请求头 响应头

https://www.cnblogs.com/lexiaofei/p/6943690.html

Linux常用操作

1.查看内存使用情况

top内存监控命令详解：https://www.cnblogs.com/zhoug2020/p/6336453.html

对于内存监控，在top里我们要时刻监控第五行swap交换分区的used，如果这个数值在不断的变化，说明内核在不断进行内存和swap的数据交换，这是真正的内存不够用了。

free内存查看命令：显示top结果的一部分，显示Mem 和 swap行。

2.查看磁盘占用情况

参考链接：https://www.cnblogs.com/vurtne-lu/p/6208581.html

df：列出文件系统的整体磁盘使用量；

du：评估文件系统的磁盘使用量（常用于评估目录所占容量）

通用参数：

-m：以MB的容量显示各文件系统

-h：以人们较易阅读的GB,MB,KB等格式自行显示

3.jetty tomcat比较

Tomcat 和 Jetty 都是作为 Servlet 引擎应用的比较广泛，可以将它们比作为中国与美国的关系，虽然 Jetty 正成长为一个优秀的 Servlet 引擎，但是目前的 Tomcat 的地位仍然难以撼动。相比较来看，它们都有各自的优点与缺点。 Tomcat 经过长时间的发展，它已经广泛的被市场接受和认可，相对 Jetty 来说 Tomcat 还是比较稳定和成熟，尤其在企业级应用方面，Tomcat 仍然是第一选择。但是随着 Jetty 的发展，Jetty 的市场份额也在不断提高，至于原因就要归功与 Jetty 的很多优点了，而这些优点也是因为 Jetty 在技术上的优势体现出来的。

架构比较：从架构上来说，显然 Jetty 比 Tomcat 更加简单，更易扩展

性能比较：单纯比较 Tomcat 与 Jetty 的性能意义不是很大，只能说在某种使用场景下，它表现的各有差异。因为它们面向的使用场景不尽相同。从架构上来看 Tomcat 在处理少数非常繁忙的连接上更有优势，也就是说连接的生命周期如果短的话，Tomcat 的总体性能更高。

而 Jetty 刚好相反，Jetty 可以同时处理大量连接而且可以长时间保持这些连接。例如像一些 web 聊天应用非常适合用 Jetty 做服务器，像淘宝的 web 旺旺就是用 Jetty 作为 Servlet 引擎。

另外由于 Jetty 的架构非常简单，作为服务器它可以按需加载组件，这样不需要的组件可以去掉，这样无形可以减少服务器本身的内存开销，处理一次请求也是可以减少产生的临时对象，这样性能也会提高。另外 Jetty 默认使用的是 NIO 技术在处理 I/O 请求上更占优势，Tomcat 默认使用的是 BIO，在处理静态资源时，Tomcat 的性能不如 Jetty。