Spring Boot 02-日志

发表于 2019-10-05 | 分类于 SpringBoot | 阅读次数:

Spring Boot日志

常见的日志抽象层有：JCL，SLF4j，jboss-logging
日志实现有：Log4j，JUL，Log4j2，Logback

SpringBoot底层Spring框架使用的是JCL，SpringBoot选用SLF4j和logback

SLF4j使用

日志记录方法的调用，要调用日志抽象层的方法

首先要给系统导入slf4j的jar包和logback的jar包

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
  public static void main(String[] args) {
    Logger logger = LoggerFactory.getLogger(HelloWorld.class);
    logger.info("Hello World");
  }
}

抽象层和具体实现之间需要导入的jar包及其关系如下（图来自官方文档）：

遗留问题

可能应用里使用的不同框架底层都有自己的日志系统，比如Spring使用的是commons-logging，Hibernate使用的是jboss-logging，需要统一日志记录，让它们一起使用slf4j进行输出（图来自官方文档）

在系统中所有日志统一到slf4j

将系统其它日志框架先排除出去
用中间包替换原有日志框架
导入slf4j其他的实现

Spring Boot日志关系

Spring Boot已经帮我们适配所有日志，底层使用slf4j+logback的方式记录日志，如果我们要引入其他框架，只需要把这个框架的默认日志依赖移除掉即可

日志的使用

Logger logger = LoggerFactory.getLogger(getClass());
logger.trace("trace");
logger.debug("debug");
logger.info("info");
logger.warn("warn");
logger.error("error");

日志的级别是trace<debug<info<warn<error
默认Spring Boot的日志级别是info，即默认只输出info及以上级别的日志信息
可以在配置文件中加入
logging.level.com.mkl.springbootdemo=trace
这样就可以在 com.mkl.springbootdemo 这个包下输出trace级别的日志信息

还可以在配置文件中指定
logging.file= ：如果不指定路径，日志输出到当前目录下指定的文件名（可以指定完整的路径）
logging.path= ：日志输出到当前磁盘根目录下指定的文件目录的spring.log文件中，如果指定了logging.file，则它不生效

指定输出日志的格式

logging.pattern.console=
logging.pattern.file=

如： %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{50} - %msg%n

%d表示日期时间
%thread表示线程名
%-5level表示级别从左显示5个字符宽度
%logger{50}表示logger名字最长50个字符
%msg表示日志消息
%n换行符

指定配置

官方文档

在类路径下配置logback.xml即可（或logback-spring.xml）

如果使用logback.xml，则直接被日志框架识别
如果使用logback-spring.xml，则日志框架不直接加载日志的配置项，由SpringBoot加载，它可以使用SpringBoot的一个高级特性

<springProfile name="staging">
	<!-- configuration to be enabled when the "staging" profile is active -->
    可以指定某段配置在某个环境生效
</springProfile>

<springProfile name="dev | staging">
	<!-- configuration to be enabled when the "dev" or "staging" profiles are active -->
</springProfile>

<springProfile name="!production">
	<!-- configuration to be enabled when the "production" profile is not active -->
</springProfile>

切换日志框架

按官网的日志适配图来切换

Spring Boot 01-入门与配置

发表于 2019-10-04 | 分类于 SpringBoot | 阅读次数:

Spring Boot入门与配置

简介

Spring Boot是简化Spring应用开发的一个框架
是整个Spring技术栈的一个大集合
是J2EE开发的一站式解决方案

优点

快速创建独立运行的Spring项目以及与主流框架集成
使用嵌入式的Servlet容器，应用无需打成WAR包
starters自动依赖与版本控制
大量的自动配置，简化开发，也可修改默认值
无需配置XML，无代码生成，开箱即用
准生产环境的运行时应用监控
与云计算的天然集成

微服务

一个应用应该是一组小型服务的组合，每个服务通过HTTP的方式进行互通，微服务架构里，每个功能元素放在一个独立的服务中，通过服务器分发这些服务进行动态扩展（在传统的单体应用中，是多个服务器复制这个单体进行扩展）

Hello World

从Spring Initializr创建一个Spring Boot应用，使用IDEA打开（打开pom）

然后导入

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

编写Controller

@ResponseBody
@RequestMapping("/hello")
public String hello() {
    return "Hello World";
}

直接运行即可，甚至不需要配置TOMCAT和MVC

配置文件

SpringBoot使用一个全局的配置文件，配置文件是固定的，只能是下面2个之1：

application.properties
application.yml

配置文件的作用：修改Spring Boot自动配置的默认值

YAML语法

.yml文件有自己的语法

k: v：表示一对键值对（v之前有空格）
以空格的缩进来控制层级关系，只要是左对齐的一列数据，都是同一个层级的
区分大小写

1
2
3

server:
    port: 8081
    path: /hello

基本类型：

字面量: 普通的值
- k: v：字面直接写，默认不需要单引号或双引号
- 双引号用于转义正常输出 zs \n ls 会输出 zs 换行 ls
- 单引号防转义 zs \n ls 会输出 zs \n ls
对象，Map
- k: v，在下一行写对象的属性和值的关系，注意缩进

1
2
3

friends:
    lastName: zhangsan
    age: 20

行内写法：

1	friends: {lastName: zhangsan,age: 20}

数组（List，Set）

pets:
 - cat
 - dog
 - pig

行内写法

1	pets: [cat,dog,pig]

为bean的属性配置值

使用yml为属性配置值

对于一个bean，可以为其配置注解 @ConfigurationProperties(prefix = "在yml配置文件中的前缀")，告诉Spring Boot这个bean所有的属性都是 application.yml 配置的属性

e.g.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-configuration-processor</artifactId>
    <optional>true</optional>
</dependency>

@Component
@ConfigurationProperties(prefix = "person")
public class Person {

    String lname;
    int age;
    boolean b;

// getter setter 略
}

person:
  lname: zhangsan
  age: 21
  b: true

使用@Value为属性配置值

@Component
public class Person {

    @Value("${person.lastName}")
    String lastName;
    @Value("#{11*2}")
    int age;
    @Value("true")
    boolean b;

// getter setter 略

}

// 支持SpEL
// `Value("${xxx}")` 从配置文件中获取值
// `Value("#{xxx}")` 计算xxx里面的表达式得出值

两个配置的区别

。	@ConfigurationProperties	@Value
功能	批量注入配置文件中的属性	一个个指定属性
松散绑定（松散语法）	支持	不支持
SpEL	不支持	支持
JSR303数据校验	支持	不支持（校验会失效）
复杂类型封装（如Map，List）	支持	不支持（用SpEL从配置文件获取会报错）

@PropertySource

在从配置文件中获取属性的时候，可以指定其他的配置文件，如新建一个person.yml，只需要为对应的bean配置 @PropertySource({"classpath:person.yml"}) 即可，注意value是一个数组，可以传入多个配置文件

@Component
@PropertySource({"classpath:person.yml"})
@ConfigurationProperties
public class Person {

    String lastName;
    int age;
    boolean b;

//getter setter
}

@ImportResource

@ImportResource(locations = {"xxx"}) 可以让我们自己写的 spring-xxx.xml 的Spring配置文件生效

@ImportResource(locations = {"classpath:xxx.xml"})
@SpringBootApplication
public class SpringbootdemoApplication {
	public static void main(String[] args) {

		SpringApplication.run(SpringbootdemoApplication.class, args);
	}
}

@Bean装载bean

Spring推荐使用注解的方法来配置bean，而不是XML

@Bean注解只能用于方法，它把方法的返回值添加到容器中，容器中这个组件默认的ID就是方法名

@Configuration
public class MyAppConfig {
    @Bean
    public HelloService helloService() {
        return new HelloService();
    }
}

注意此时HelloService不能被 @Component 及其3个子注解注解

@Bean与@Component的区别

它们都是用于把bean注册到Spring容器中

@Component(@Controller,@Service,@Repository)通常通过路径扫描来自动侦测以及自动装配到Spring容器（在Spring Boot中，自动侦测通过@EnableAutoConfiguration默认配置，范围是主类的包及子包）
@Bean通常在标有该注解的方法中定义产生这个bean的逻辑

yml(properties)配置文件的占位符

${random.xxx}：可以设置随机的值
可以使用内部的其他值

person.id = ${random.int}
person.name = ${person.id:123}zhangsan;
// 如果没有person.id，就使用123作为默认值

随机数如下：
${random.value},${random.int},${random.long}
${random.int(10)},${random.[123,456]}

Profile

Profile是Spring对不同环境提供不同配置功能的支持

如果使用的是properties
在主配置文件编写的时候，文件名可以是 application-{profile}.properties。（比如生产环境是application-prod.properties，开发环境是application-dev.properties）
默认使用的是application.properties的配置，如果要使用其他的环境，只需要在默认的环境加上： spring.profiles.active=dev（dev可以换成prod）即可

如果使用yml
文档快可以使用文档块，然后在最上面的默认块使用 spring:profiles:actice 指定环境即可

server:
  port: 8081
spring:
  profiles:
    active: dev

---

server:
  port: 80
spring:
  profiles: dev

---
server:

  port: 8084
spring:
  profiles: prod

也可以在命令行输入 java -jar xxx.jar --spring.prifile.actice=dev 来指定

配置文件的加载位置

Spring Boot启动会扫描以下位置的application.properties或者application.yml文件作为默认配置文件，从下面的路径加载

file:./config/ （当前项目的根的config目录）
file:./ （当前项目的根目录）
classpath:/config/
classpath:/

它们的优先级从高到低，高优先级的配置会覆盖低优先级的配置
如果4个配置文件都存在，则它们是按优先级互补配置（比如高优先级的文件没有某个配置，则从低优先级的文件获取）

Conditional

所有ConditionnalXxx注解都是基于@Conditional的，比如 ConditionalOnClass ，它有一个 @Conditional({OnClassCondition.class}) 的注解，Conditional的扩展如下

@Conditional扩展注解	作用（判断是否满足当前指定条件）
@ConditionalOnJava	系统的java版本是否符合要求
@ConditionalOnBean	容器中存在指定Bean
@ConditionalOnOnMissingBean	容器中不存在指定Bean
@ConditionalOnOnExpression	满足SpEL表达式指定
@ConditionalOnClass	系统中有指定的类
@ConditionalOnMissingClass	系统中没有指定的类
@ConditionalOnSingleCandidate	容器中只有一个指定的Bean，或者这个Bean是首选Bean
@ConditionalOnProperty	系统中指定的属性是否有指定的值
@ConditionalOnResourve	类路径下是否存在指定资源文件
@ConditionalOnWebApplication	当前是Web环境
@ConditionalOnNotWebApplication	当前不是Web环境
@ConditionalOnJndi	JNDI存在指定项

可以通过在配置文件中 debug=true 来让控制台打印自动配置报告，可以让我们知道哪些自动配置类生效

自动配置原理

Spring Boot启动的时候加载主配置类，开启自动配置功能 @EnableAutoConfiguration
@EnableAutoConfiguration作用：
- Import注解引入AutoConfigurationImportSelector给容器导入一些组件，它调用selectImports方法获取
- selectImports方法实质上调用的是 List<String> configurations = this.getCandidateConfigurations(annotationMetadata, attributes); 它扫描所有jar包类路径下的 META-INF/spring.factories 这个文件
- 把扫描到的这些文件的内容包装成 Porperties 对象
- （可能未完成或者不够充分，等以后再补）
- 综上，@EnableAutoConfiguration 的作用是将类路径下META-INF/spring.factories里配置的所有EnableAutoConfiguration的值加入到容器中（在org.springframework.boot:spring-boot-autoconfigure包），每一个xxxAutoConfiguration类都是容器的一个组件，都加入到容器中，用它们来做自动配置
每个自动配置类进行自动配置功能
以HttpEncodingAutoConfiguraion为例解释自动配置的流程

@Configuration // 表示这是一个配置类
@EnableConfigurationProperties({HttpProperties.class}) // 启动指定类的ConfigurationProperties功能；将HttpProperties的值和配置文件中对应的值绑定起来
@ConditionalOnWebApplication(
    type = Type.SERVLET
) // 如果是Web应用，这个配置文件才生效，否则不生效
@ConditionalOnClass({CharacterEncodingFilter.class})  // 判断当前项目有没有CharacterEncodingFilter这个类，有则生效
@ConditionalOnProperty(
    prefix = "spring.http.encoding",
    value = {"enabled"},
    matchIfMissing = true
) // 判断配置文件是否存在spring.http.encoding这个配置，但是即使不存在，它也成立
public class HttpEncodingAutoConfiguration {

根据当前不同条件，判断自动配置类是否生效
它有一个注解 @EnableConfigurationProperties({HttpProperties.class}) ，作用是启动指定类的ConfigurationProperties功能，（告诉Spring Boot这个bean所有的属性都是 HttpProperties.class 配置）
这个HttpProperties有一个注解 @ConfigurationProperties(prefix = "spring.http")，它的作用是从配置文件中获取 spring.http 前缀的值，然后封装到自己内部对应的属性上，然后交还给自动配置类去使用。
所有在配置文件中能配置的属性都是在xxxProperties类中封装，配置文件能配置什么就可以参照某个功能对应的这个属性类
自动配置类就去配置对应功能相关的Bean

综上所述：

SpringBoot启动时会加载大量的自动配置类
我们需要哪些功能，如果SpringBoot默认写好自动配置类，就不需要我们再去写
需要配置某些属性的时候，可以在配置文件中配置，对应自动配置类会通过xxxProperties从中获取

Java IO

发表于 2019-09-26 | 分类于 Java | 阅读次数:

Java IO

https://zhuanlan.zhihu.com/p/28286559

框架

要记住Java IO包是通过装饰者模式来实现IO的

对类结构进行分类，IO可以分为：

字节流和字符流：
- 字节流：以字节为单位，每次读入或读出都是8位数据，可以读任何类型的数据
- 字符流：以字符为单位，每次读入或读出都是16位数据，只能读取Unicode字符型数据
输出流和输入流：
- 输出流：从内存读出到文件，只能进行写操作
- 输入流：从文件读入到内存，只能进行读操作
节点流和处理流：
- 节点流：直接与数据源相连，读入或读出
- 处理流：与节点流一块使用，在节点流的基础上，再套接一层，套接在节点流上的就是处理流

图如下：

其他说明：

节点流中的字节/字符数组流，是在内存中开辟一个字节或字符数组
处理流有如下几种类型
- 缓冲流：Buffered开头的，缓冲区作用是减少硬盘IO次数
- 转换流：InputStreamReader和OutputStreamWriter，把字节转换为字符
- 基本类型数据流：DataInputStream和DataOutputStream，它提供readXxx()方法，
- 打印流：PrintStream和PrintWriter，一般是打印到控制台，可以进行控制打印的地方
- 对象流：ObjectInput(Output)Stream，对象序列化和反序列化的流
- 合并流：SequenceInputStream：可以认为是一个工具类，将两个或多个输入流当成一个输入流依次读取

File对象

创建一个File对象如下：

1
2
3

String fileName = "D:" + File.separator + "my.txt";
File file = new File(fileName);
// 然后把该File传递给对应的节点流

基本类型数据流

String fileName= "c:" + File.separator + "Users" + File.separator + "MakaLoo" + File.separator + "Desktop" + File.separator + "hello.txt";
File file = new File(fileName);
OutputStream out = new DataOutputStream(new FileOutputStream(file));
((DataOutputStream) out).writeDouble(123.456);
out.close();

DataInputStream in = new DataInputStream(new FileInputStream(file));
double d = in.readDouble();
System.out.println(d);
in.close();

字符流与字节流的转换

InputStreamReader：输入的字节流转换为字符流

String fileName = "d:" + File.separator + "hello.txt";
File file = new File(fileName);
// 不使用Buffered装饰也可以
// Writer out = new OutputStreamWriter(new BufferedOutputStream(new FileOutputStream(file)));
Writer out = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(file)));
// 传入输出字节流对象，写的时候是写字符，它会转换
out.write("hello");
out.close();

OutputStreamWriter：输出的字节流转换为字符流

String fileName = "d:" + File.separator + "hello.txt";
File file = new File(fileName);
// Reader in = new BufferedReader(new InputStreamReader(new FileInputStream(file)));
Reader in = new InputStreamReader(new BufferedInputStream(new FileInputStream(file)));
char[] c = new char[100];
int length = in.read(c);
System.out.println(String.valueOf(c, 0, length));
in.close();

HeadFirst设计模式-观察者模式

发表于 2019-09-05 | 分类于设计模式 | 阅读次数:

HeadFirst设计模式-观察者模式

案例分析

现在有一个项目，是要负责开发一个气象台实时显示的内容，如下：

气象站会提供给我们一个WeatherData对象，我们需要实现的是：建立一个应用，利用WeathrerData对象取得数据，并更新三个布告板：目前状况，气象统计和天气预报

public class WeatherData {
    getTemperature() { // 从气象台取得温度 }
    getHumidity() { // 从气象台取得湿度 }
    getTemperature() { // 从气象台取得压力 }
    measurementsChanged() { // 一旦气象测量更新，此方法会被调用，需要我们具体实现 }
}

目前得到的情报：

WeatherData类有对应参数的getter方法
新的测量数据备妥时，measurementsChanged()会自动调用
我们需要实现三个布告板：目前状况布告，气象统计布告和天气预报布告，一旦WeatherData有新的测量，这些布告马上更新
这个系统可以扩展，用户可以随心所欲添加或删除任何布告板

初步设计方案

public class WeatherData {
    measurementsChanged() {
        // 一旦气象测量更新，此方法会被调用，需要我们具体实现 
        float temp = getTemperature();
        float humidity = getHumidity();
        float pressure = getPressure();

        currentConditionsDisplay.update(temp, humidity, pressure);
        statisticsDisplay.update(temp, humidity, pressure);
        forecastDisplay.update(temp, humidity, pressure);
    }
}

遇到问题

这个初步方案看似完成了功能，但实际上它会遇到如下问题：

对于每个新的布告板，我们都得修改代码
无法运行时动态增加或删除布告板
没有封装改变的部分
针对具体实现编程，而非针对接口

解决方案

我们可以使用观察者模式来解决这个方案，什么是观察者模式？可以通过订阅报纸来类比：

报社的业务是出版报纸
向某家报社订阅报纸，只要他们有新的报纸出版，就会送上门，只要我们一直是订户，报社就会持续给我们送上报纸
当我们不想再看这家报社的报纸了，我们可以取消订阅，他们就不会再送报纸过来了
只要报社还在运营，就会持续有人订阅报纸和取订报纸

观察者模式就是这样，只不过它的专业名词有点区别，出版社实际上就是观察者模式的主题Subject，而订阅者就是观察者Observer

使用上面所述的观察者，气象台的应用可以如下设计：

public interface Subject {
    public void registerObserver(Observer o);
    public void removeObserver(Observer o);
    public void notifyObservers(); // 主题状态改变，则通知所有观察者
}

public interface Observer {
    public void update(float temp, float humidity, float pressure);
}

public interface DisplayElement {
    // 布告板的显示
    public void display();
}

public class WeatherData implements Subject {
    private ArrayList observers;
    private float temperature;
    private float humidity;
    private float pressure;

    public WeatherData() {
        observers = new ArrayList();
    }

    public void registerObserver(Observer o) {
        observers.add(o);
    }

    public void removeObserver(Observer o) {
        int i = observers.indexOf(o);
        if (i >= 0)
            observers.remove(i);
    }

    public void notifyObservers() {
        for (int i = 0; i < observers.size(); i++) {
            Observer ob = (Observer) observers.get(i);
            observer.update(temperature, humidity, pressure); // 通知每个观察者去执行响应的update操作
        }
    }

    public void measurementsChanged() {
        notifyObservers();
    }

    public void setMeasurements(float temperature, float humidity, float pressure) {
        this.temperature = temperature;
        this.humidity = humidity;
        this.pressure = pressure;
        measurementsChanged();
    }
}

public class CurrentConditionsDisplay implements Observer, DisplayElement {
    private float temperature;
    private float humidity;
    private Subject weatherData;

    public CurrentConditionsDisplay(Subject weatherData) {
        this.weatherData = weatherData;
        weatherData.registerObserver(this); // 订阅这个主题
    }

    public void update(float temperature, float humidity, float pressure) {
        this.temperature = temperature;
        this.humidity = humidity;
        display();
    }

    public void display() {
        System.out.println(xxxxx);
    }
}

本章总结-观察者模式

观察者模式：定义了对象之间一对多依赖，这样依赖，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新

主题对象管理某些数据，当数据发生变化，就会通知观察者（推或拉），观察者就会针对这些新数据作出相应的更新操作，主题是真正拥有数据的人，观察者是主题的依赖者，在数据变化时更新，观察者模式也实现了编程一个约定俗成的设计原则：松耦合

观察者模式还有一个推和拉的区别：

推就是主题把自己的更新推给所有观察者，但问题就是部分观察者不想要所有的数据，如果有些观察者只需要一两个数据，但每次都接收所有的数据
拉就是观察者自己把主题的数据拉过来，但问题就是拉的时机不确定，如果过短则导致多次拉数据都是重复数据，过长则数据得不到实时有效更新
选择推或拉主要还是根据业务来决定

Java内置的观察者模式

Java内置的观察者模式为java.util.Observer和java.util.Observable，它们分别是观察者和主题，内部使用vector维护所有观察者，使用布尔变量changed指示状态发生变化，每次都要调用setChanged()标记状态已经改变，然后调用notifyObservers()或notifyObservers(Object arg)（arg传送任何数据给观察者）来通知观察者

但它也有它不好的地方：

主题是一个类（Observable），不能实现多继承
setChanged()方法是protected，只能使用继承才能调用该方法，不能创建一个Observable实例然后组合到自己对象，违反了多用组合，少用继承原则

HeadFirst设计模式-入门&策略模式

发表于 2019-09-03 | 分类于设计模式 | 阅读次数:

HeadFirst设计模式-入门&策略模式

案例分析

假设我们需要做一个模拟鸭子游戏，叫SimUDuck，游戏中会出现各类鸭子，一边游泳戏水，一边呱呱叫

初步设计方案

public abstract class Duck {
    quack(); // 叫
    swim();  // 游
    display(); // 外观，抽象方法
    // 其他办法
}

class MallardDuck extends Duck {
    display() {
        // 外观是绿头
    }
}

class RedheadDuck extends Duck {
    display() {
        // 外观是红头
    }
}

遇到问题

鸭子需要添加fly()，但如果为超类添加fly()方法，会导致所有子类的有该方法，一些不应该的飞的鸭子（比如橡皮鸭，诱饵鸭等假鸭）也会飞起来，如果利用继承来提供Duck的行为，会导致下列缺点：

代码在多个子类中重复
运行时的行为不容易改变
很难知道所有鸭子的全部行为
改变会牵一发而动全身，造成其他鸭子不想要的改变

如果改用接口，如：

public abstract class Duck {
    swim();  // 游
    display(); // 外观，抽象方法
    // 其他办法
}

interface Flyable {
    fly();
}

interface Quackable {
    quack();
}

class MallardDuck extends Duck implements Flyable, Quackable {
    display() {
        // 外观是绿头
    }
    fly() { }
    quack() { }
}

class RedheadDuck extends Duck implements Flyable, Quackable {
    display() {
        // 外观是红头
    }
    fly() { }
    quack() { }
}

这样会导致重复的代码极多，比如我有200个鸭子，每个鸭子的飞行都只有一丁点的区别，这样，没有区别的代码量就会很多，且不能复用，导致代码质量极差

解决方案

有一个设计原则，恰好适用于这种情况：找出应用中可能需要变化的地方，把他们独立出来，不要和那些不需要变化的代码混合在一起

我们把上面的会发生变化的飞行行为和鸣叫行为独立出来，设计成接口，然后再写它们的具体实现类，然后在超类Duck中定义这些类的成员，这样，对于每个Duck的不同子类，它们的飞行和鸣叫行为就可以独立出来，既做到了代码复用，也可以让不同子类的行为具有不同的实现方式

public interface FlyBehavior {
    public void fly();
}

public interface QuackBehavior {
    public void quack();
}

public class Quack implements QuackBehavior {
    public void quack() {
        // perform quack behavior
    }
}

public class FlyWithWings implements QuackBehavior {
    public void fly() {
        // perform fly behavior
    }
}

public class Duck {
    FlyBehavior flyBehavior;
    QuackBehavior quackBehavior;

    public void setFlyBehavior(FlyBehavior fb) {
        flyBehavior = fb;
    }

    public void setQuackBehavior(QuackBehavior qb) {
        quackBehavior = qb;
    }

    performQuack() {
        quackBehavior.quack();
    }

    performFly() {
        flyBehavior.fly();
    }
    swim() {}
    display() {}
    // 其他行为
}

public class MallardDuck extends Duck {
    public MallardDuck() {
        quackBehavior = new Quack();
        flyBehavior = new FlyWithWinds();
    }

    performQuack() {
        quackBehavior.quack();
    }

    performFly() {
        flyBehavior.fly();
    }
    swim() {}
    display() {}
    // 其他行为
}

可以发现我们在Duck类使用的是接口类型的变量，而不是实际类型，这样鸭子类不会管这些行为的具体实现，具体实现由实现类来实现，且不同的鸭子可以有不同的实现，可以在运行时动态地改变它们的行为，这就是我们的第二个设计原则：针对接口编程，而不是针对实现编程

这种使用接口变量的方式，会比直接使用继承更好，代码会容易维护，这就是我们的第三个设计原则：多用组合，少用继承

本章总结

设计模式是前辈们对代码开发经验的总结，是解决特定问题的一系列套路，是一套用来提高代码可复用性，可维护性，可读性，稳健性以及安全性的解决方案
三个设计原则
- 把会发生变化的地方从不变的地方独立出来
- 针对接口编程，而不是针对实现编程，针对接口编程实际上就是针对超类编程，也就是多态性
- 多用组合，少用继承
上面所使用的设计模式，就是策略模式
策略模式作为一种软件设计模式，指对象有某个行为，但是在不同的场景中，该行为有不同的实现算法
策略模式的组成：
- 抽象策略角色：策略类，通常由一个接口或者抽象类实现
- 具体策略角色：包装了相关的算法和行为
- 环境角色：持有一个策略类的引用，最终给客户端调用
策略模式主要应用于多个类只区别在表现行为不同，或在不同情况下使用不同的策略的场景，它对客户隐藏了具体策略的实现细节

设计模式（持续更新）

发表于 2019-09-01 | 分类于面经 | 阅读次数:

设计模式（持续更新）

策略模式

策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户

缺点

客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。换言之，策略模式只适用于客户端知道算法或行为的情况。
由于策略模式把每个具体的策略实现都单独封装成为类，如果备选的策略很多的话，那么这些类的数目就非常多了。

使用

一个抽象策略类（Strategy）（接口），它定义了具体策略类的具体算法的抽象公共接口，所有具体策略类都要实现该接口
一堆具体策略类（ConcreteStrategy）
环境类（Context）：维护一个对Strategy对象的引用，用一个ConcreteStrategy对象类配置，它可以定义setter接口来设置具体的ConcreteStrategy，定义另一个接口使用策略的算法

观察者模式

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象(主题)改变状态时，它的所有依赖者(观察者)都会收到通知并自动更新，主题真正拥有数据

使用

Java内置有Observable和Observer类，Observer就是观察者，Observable是主题，Observable是类，而不是接口，限制复用能力，所以最好自己设计观察者模式

装饰者模式

利用组合（composition）和委托（delegation）可以在运行时实现继承行为的效果，动态地给对象加上新的行为
利用继承扩展子类的行为，是在编译时静态决定的；利用组合的做法，可以在运行时动态地扩展对象的行为

装饰者模式动态地将责任附加到对象上，若要扩展功能，装饰者提供了比继承更有弹性的替代方案
装饰者模式中，装饰者可以在被装饰者的行为之前或之后，加上自己的行为，以实现特性的目的

软件设计原则：类应该对扩展开放，对修改关闭

缺点：

设计中加入大量的小类，代码不容易理解
客户端代码依赖于特定类型（违反针对接口编程）
使实例化组件的复杂度提升

使用

装饰者和被装饰对象具有相同的超类型（接口）
可以用一个或多个装饰者包装一个对象
每个装饰者都可以通过组合和构造器参数形式传入被装饰者
定义一个超类型的对象指向最外层装饰者，调用最外层装饰者对应的方法，最外层装饰者会依次调用内部装饰者直到被装饰者的方法
装饰者自己的方法在调用被装饰者的方法前后会加入自己的行为，以达到某个目的

工厂模式

简单工厂模式

工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类

它的优点是：

创建对象只需要知道其名字
扩展性高，如果增加一个产品，只需要扩展工厂类
屏蔽产品的具体实现，调用者只关心产品的接口

缺点：

每次增加一个产品时，都需要增加一个具体类和对象实现工厂

使用

public interface Shape {
   void draw();
}

public class Rectangle implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Rectangle::draw() method.");
   }
}

public class Square implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Square::draw() method.");
   }
}

public class Circle implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Circle::draw() method.");
   }
}

public abstract class AbstractShapeFactory {
    public abstract Shape getShape(String shapeType) {}
}

public class ShapeFactory extends AbstractShapeFactory {
    
   //使用 getShape 方法获取形状类型的对象
   public Shape getShape(String shapeType){
      if(shapeType == null){
         return null;
      }        
      if(shapeType.equalsIgnoreCase("CIRCLE")){
         return new Circle();
      } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
         return new Rectangle();
      } else if(shapeType.equalsIgnoreCase("SQUARE")){
         return new Square();
      }
      return null;
   }
}

抽象工厂模式

抽象工厂模式提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类

优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象

缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的实现类加代码

使用

public interface Shape {
   void draw();
}

public class Rectangle implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Rectangle::draw() method.");
   }
}

public class Square implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Square::draw() method.");
   }
}

public class Circle implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Circle::draw() method.");
   }
}

public interface Color {
   void fill();
}

public class Red implements Color {
 
   @Override
   public void fill() {
      System.out.println("Inside Red::fill() method.");
   }
}

public class Green implements Color {
 
   @Override
   public void fill() {
      System.out.println("Inside Green::fill() method.");
   }
}

public class Blue implements Color {
 
   @Override
   public void fill() {
      System.out.println("Inside Blue::fill() method.");
   }
}

public abstract class AbstractFactory {
   public abstract Color getColor(String color);
   public abstract Shape getShape(String shape);
}

public class ShapeFactory extends AbstractFactory {
    
   @Override
   public Shape getShape(String shapeType){
      if(shapeType == null){
         return null;
      }        
      if(shapeType.equalsIgnoreCase("CIRCLE")){
         return new Circle();
      } else if(shapeType.equalsIgnoreCase("RECTANGLE")){
         return new Rectangle();
      } else if(shapeType.equalsIgnoreCase("SQUARE")){
         return new Square();
      }
      return null;
   }
   
   @Override
   public Color getColor(String color) {
      return null;
   }
}

public class ColorFactory extends AbstractFactory {
    
   @Override
   public Shape getShape(String shapeType){
      return null;
   }
   
   @Override
   public Color getColor(String color) {
      if(color == null){
         return null;
      }        
      if(color.equalsIgnoreCase("RED")){
         return new Red();
      } else if(color.equalsIgnoreCase("GREEN")){
         return new Green();
      } else if(color.equalsIgnoreCase("BLUE")){
         return new Blue();
      }
      return null;
   }
}

public class FactoryProducer {
   public static AbstractFactory getFactory(String choice){
      if(choice.equalsIgnoreCase("SHAPE")){
         return new ShapeFactory();
      } else if(choice.equalsIgnoreCase("COLOR")){
         return new ColorFactory();
      }
      return null;
   }
}

public class AbstractFactoryPatternDemo {
   public static void main(String[] args) {
 
      //获取形状工厂
      AbstractFactory shapeFactory = FactoryProducer.getFactory("SHAPE");
      //获取形状为 Circle 的对象
      Shape shape1 = shapeFactory.getShape("CIRCLE");

      //获取颜色工厂
      AbstractFactory colorFactory = FactoryProducer.getFactory("COLOR");
      //获取颜色为 Red 的对象
      Color color1 = colorFactory.getColor("RED");
   }
}

工厂与抽象工厂的区别

我个人觉得抽象工厂可以理解为产品族的工厂，它有一系列负责生产不同产品的方法，这些方法由子类去具体实现，不同子类负责具体某些（或某个）产品的生产，它是通过组合实现的
而工厂模式主要是生产某个具体产品，通过继承实现

单例模式

单例模式确保一个类只有一个实例，并且提供一个全局访问点

双检锁

public class Singleton{
    private static volatile Singleton single;
    private Singleton(){}
    
    public static Singleton getSingle() {
        if(single == null) { // 第一次检查是防止已有单例的情况下进入同步块增加开销
            synchronized (Singleton.class) {
                if (single == null) // 第二次是防止两个线程同时进入同步块，第一个返回一个new Singleton()后，第二个线程也创建一个新的Singleton()
                    single = new Singleton();
            }
        }
        return single;
    }
}

// 饿汉
public class Singleton{
    private static Singleton single = newSingleton();
    private Singleton(){}
    
    public static Singleton getSingle() {
        return single;
    }
}

// 懒汉
public class Singleton{
    private static Singleton single;
    private Singleton(){}
    
    public static Singleton getSingle() {
        if (single == null)
            single = new Singleton();
        return single;
    }
}

命令模式

适配器模式与外观模式

模板方法模式

模板方法模式在一个方法中定义一个算法的框架，而将一些步骤延迟到子类，模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤

与策略模式的区别：

策略模式是定义和封装一组算法族，用委托和组合的方式选择具体的算法

而模板模式是定义一个算法的框架，由子类去实现某些步骤（Java Arrays.sort()使用的也是模板）

迭代器与组合模式

状态模式

代理模式

设计原则

找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起
- 这样可以方便以后对其进行改动或扩充，而不影响变化的其他部分
针对接口(超类型)编程，而不是针对实现编程
- 针对实现编程，要改变行为的时候十分不方便，但如果针对接口编程，就会很方便，实际实现不会具体绑定在实体类上
多用组合，少用继承
- 使用组合具有很大弹性，可以将算法族(每个算法)封装成类，也可以运行时动态改变行为
为了交互对象之间的松耦合设计而努力
类应该对扩展开放，对修改关闭
依赖倒置原则：要依赖抽象，不要依赖具体类

其他（持续更新）

发表于 2019-09-01 | 分类于面经 | 阅读次数:

其他

正则表达式

^ 串的开始
$ 串的结束
\ 原义字符，八进制字符
"abc" 匹配包含aaabcccc abc123
* 前的子表达式匹配0-多次（ac*可以匹配acccc或a）
+ 前的子表达式匹配1-多次（ac+可以匹配ac，acccc）
? 前的子表达式匹配0次或1次（ac?可以匹配ac，a）

{n} n是非负整数，表示匹配n次（ab{2}可以匹配abb）
{n,} 匹配至少n次（ab{2,}，可以匹配abb，abbb）
{n,m} 匹配n-m次（ab{2,5}，可以匹配abb，abbbbb）

| 或
. 任何符号

[abc] a或b或c
[^abc] 没有a，b，c
[a-z] 存在一个a到z之间的字符
[0-9] 存在一个0到9之间的字符
[^a-z] 不存在a到z之间的字符
^[a-z] 以a-z开头

\d 一个数字
\D 非数字
\w 等价于[0-9a-zA-Z]
\W 等价于[^0-9a-zA-Z]
\f 换页
\n 换行
\r 回车
\s 任何空白字符（空格，制表等）
\S 任何非空白字符
\t 制表

贪婪匹配： 对于aabab，a.*b 会匹配aabab
懒惰匹配： 对于aabab，a.*?B会匹配aab
（只要加上问号就可以取消贪婪匹配）

JSON

对象：{"name": "John Doe", "age": 18, "address": {"country" : "china", "zip-code": "10000"}}
数组：[3, 1, 4, 1, 5, 9, 2, 6]
字符串：双引号
数组

JVM（持续更新）

发表于 2019-09-01 | 分类于面经 | 阅读次数:

JVM

JVM组成

类加载器（ClassLoader）
运行时数据区（Runtime Data Area）
执行引擎（Execution Engine）
本地库接口（Native Interface）

程序在执行之前先要把java代码转换成字节码（class文件），jvm首先需要把字节码通过一定的方式 类加载器（ClassLoader） 把文件加载到内存中 运行时数据区（Runtime Data Area） ，而字节码文件是jvm的一套指令集规范，并不能直接交个底层操作系统去执行，因此需要特定的命令解析器 执行引擎（Execution Engine） 将字节码翻译成底层系统指令再交由CPU去执行，而这个过程中需要调用其他语言的接口 本地库接口（Native Interface）来实现整个程序的功能，这就是这4个主要组成部分的职责与功能。

JVM内存模型

程序计数器：PC指针指向下一条需要执行的字节码指令，线程私有
虚拟机栈：方法栈，存储局部变量表，操作数栈，动态链接，方法出口等（线程请求的栈深度大于虚拟机允许的深度时，抛出StackOverflowError，虚拟机栈动态扩展时无法申请到足够内存，抛出OutOfMemoryError），线程私有
- 局部变量表存放的是8大基础类型加上一个引用类型，所以还是一个指向地址的指针
本地方法栈，Native方法，线程私有
堆：存放对象实例，GC主要区域，会抛出OOM错误，线程共享
方法区：存储已被虚拟机加载的类信息，常量，静态变量，即时编译器编译后的代码等数据，线程共享
- 运行时常量池：存放编译器生成的字面量和符号引用

对象创建步骤

检查方法区常量池是否有该类的符号引用，没有则类加载（类加载过程在后面）
分配内存，策略有空闲表法和指针碰撞
分配的内存空间初始化为0
设置对象头的必要信息如哈希码，GC分代年龄等
Java执行init方法

Java对象结构

对象头：GC分代，锁，哈希码等，Java数组的话还有数组长度的数据
实例数据：对象真正有效的信息
对其填充：8字节的整数倍

Java对象定位方式

句柄访问：Java堆中有一个句柄池，句柄池每个对象有2个指针，一个是到对象实例数据的指针，一个是到对象类型数据的指针，栈的本地变量表的reference指向句柄池，句柄池到对象实例数据的指针指向对象实例数据，到对象类型数据的指针指向方法区的对象类型数据

直接指针访问：Hotspot使用的是这个访问方式，reference对象直接指向堆中对象，该对象有一个指向对象类型数据的指针指向方法区的对象类型数据

它们的区别主要是reference一个指向堆中的句柄池，通过句柄池再指向堆中的实例，而另一个reference直接指向对象实例

堆内的分区

分为新生代和老年代（java 8取消永久代），新生代包括Eden+Survivor区，Survivor区分为from和to区

GC判定方法

引用计数法：给对象添加引用计数器，每当一个地方引用它，计数器就加1，引用失效时，计数器减1，计数值为0就回收，无法解决相互循环引用的问题
引用链法（可达性分析）：GC Roots开始往下搜索，所经过路径为引用链，只要对象与GC Roots没有任何引用链相连，证明此对象不可达，应被回收。GC Roots为：虚拟机栈引用的对象，本地方法栈引用的对象，方法区类静态属性引用的对象，方法区常量引用的对象

Java引用

强引用：常见的都是强引用，垃圾回收器不会回收被强引用引用的对象
软引用：有用但不是必需，发送内存溢出异常之前被回收
弱引用：有用但不是必需，下一次GC被回收
虚引用：无法通过虚引用获得对象，用在GC时返回一个通知

回收方法区

回收价值很低

该类所有实例都被回收
加载该类的ClassLoader已经被回收
该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方利用反射访问该类

垃圾回收算法

标记-清除：会导致不连续的内存碎片，分配较大对象触发GC
复制：内存分为大小相等的两块，每次GC将存活的对象复制到另外一块，然后把已使用的内存空间一次清理掉，代价是内存只有原来一半
- 现在的虚拟机都采用复制算法回收新生代，但是是将内存分为一块较大的Eden空间和两块较小的Survivor空间(8:1:1)，每次使用Eden和其中一块Survivor，新对象在Eden分配内存，回收时将Eden和Survivor中还存活的对象一次性复制到另外一块Survivor中
标记-整理：标记整理在标记后，把存活对象都向一端移动，然后直接清理端边界以外的内存，适用于老年代

安全点

引用关系不会发生变化的点

垃圾回收器

Serial：单线程，新生代，采取复制算法
ParNew：多线程，新生代，采取复制算法
Parallel Scavenge：新生代，多线程，更注重吞吐量
Serial Old：Serial的老年代版本，采取标记-整理算法
Parallel Old：Parallel的老年代版本，多线程

CMS

以最短回收停顿时间为目的

初始标记->并发标记->重新标记->并发清除

初始标记(单线程)和重新标记(多线程)需要Stop The World，初始标记主要标记GC Roots能直接关联到的对象，并发标记是GC Roots Tracing过程，重新标记是修正并发标记过程中因程序运行而变动的部分

缺点：

对CPU资源敏感，因为它是并发标记的，会占用一部分CPU导致程序变慢
无法处理浮动垃圾，可能导致Full GC
基于标记-清除算法，产生大量空间碎片

G1

G1把Java堆内存划分为多个大小相等的Region，新生代老年代都是一部分Region的集合，G1跟踪各个Region的垃圾堆积的价值大小（回收可获得的空间和回收所需时间），后台维护一个优先队列，每次回收价值最大的Region

初始标记->并发标记->最终标记->筛选回收

G1整体看是基于标记-整理算法，局部（两个Region之间）看是基于复制算法

内存分配策略

对象优先在Eden分配，Eden没有足够空间时，发起一次Minor GC
大对象直接进入老年代（字符串，数组）
长期存活的对象进入老年代（默认15岁）
动态对象年龄判定：Survivor相同年龄所有对象大小总和大于Survivor空间的一半，年龄大于等于该年龄的对象直接进入老年代
空间分配担保：Minor GC前，虚拟机先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果成立则Minor GC安全，不成立则查看相关参数是否允许担保失败，如果允许，会继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于就进行一次Minor GC，尽管这次GC是有风险的，如果小于，进行一次Full GC

JVM性能调优

-Xmx：堆最大内存数
-Xms：堆初始化大小
-Xmn：堆新生代初始即最大大小
-Xss：线程栈大小
-XX:SurvivorRatio=n：Survivor与Eden大小比例是2:n，n默认为8
-XX:NewRatio=n：年轻代和老年代比值为1：n
-XX:newSize：新生代大小
-XX:MaxNewSize：新生代最大大小

GC原因

年轻代的GC是Minor GC，老年代的GC是Full GC

Minor GC原因

Eden区满，触发新生代Minor GC将Eden和非空闲Survivor存活的对象复制到另一个空闲Survivor中
Survivor区满，Minor GC将对象复制到老年代

Full GC原因

老年代被写满
System.gc()调用
统计得到的Minor GC晋升到老年代的平均大小大于老年代的剩余空间

类文件结构

Class文件为8字节为单位的二进制流，采用伪结构，只有两种数据类型：无符号数和表
无符号数有u1，u2，u4和u8

从上往下Class文件结构为：魔数（0xCAFEBABE），次版本（2字节），主版本（2字节），常量池，访问标志，类索引，父类索引，接口索引，字段表，方法表，属性表

类生命周期

加载->连接->初始化->使用->卸载

虚拟机类加载机制

类加载指将Class文件的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构

加载->连接->初始化

连接又分为：验证->准备->解析

加载：文件加载到内存，通过类的完全限定名查找此类字节码文件，并利用字节码文件创建一个Class对象

验证：目的在于确保Class文件符合当前虚拟机要求，不会危害虚拟机自身安全，分为文件格式验证，元数据验证(类)，字节码(方法字段)验证，符号引用验证(能否通过全限定名找到该类)

准备：为类变量分配内存并设置初始值的阶段，初始值为0或null

解析：虚拟机将常量池内的符号引用转换为直接引用的过程，解析阶段可能发生在初始化之后（为了支持动态绑定）

初始化：执行类构造器<clinit>()方法，即执行类变量的赋值和静态语句块

类加载器

Java自带的三种类加载器分别是：Bootstrap ClassLoader（启动类加载器），Extension ClassLoader（扩展类加载器），Application ClassLoader（应用程序类加载器），除此之外可以自定义类加载器

启动类加载器用来加载 Java 的核心库(jre/lib/rt.jar)，原生C++实现，并不继承自java.lang.ClassLoader
扩展类加载器是加载jre/ext/*.jar
系统类加载器（应用程序类加载器）根据 Java 应用的类路径（CLASSPATH）来加载 Java 类

双亲委派模型：除了顶层的启动类加载器外，其余的类加载器都有自己的父类加载器。如果一个类加载器收到类加载的请求，它不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，最终传送到顶层的启动类加载器中，只有父加载器反馈自己无法完成这个加载请求时（它的搜索范围没有找到所需的类），子加载器才自己去尝试加载

双亲委派模式的好处：

多加载器加载某个类时，最终都是由一个加载器加载，确保最终加载结果相同

如何写自己的ClassLoader

继承ClassLoader
重写findClass()方法
调用defineClass()方法

简述分派

分派与多态性是相关的

静态分派：发生在编译时期，所有依赖静态类型来定位方法执行版本的分派称为静态分派，典型应用为方法重载（2个同名方法，一个参数是父类Human，另一个参数是其子类Man，Human man = new Man()，传入该man参数，调用的是参数为Human的方法）
动态分派：在运行期根据实际类型确定方法执行版本的分派过程。典型应用为方法重写（最终调用的方法一般上来说是实际类型的方法，如果没有则往上搜索其父类的方法）

虚拟机运行时栈帧结构

局部变量表：存放方法参数和方法内部定义的局部变量
操作数栈：存放8大基本数据类型和reference（byte，short和char会转换为int，方法内int a = 123;a存放在局部变量表，123存放在操作数栈）
动态链接：运行期间转换为直接引用的符号引用
方法返回地址

Java内存模型

规定所有变量都存储在主内存中，每条线程都有自己的工作内存（可以类比高速缓存），线程的工作内存中保存了被该线程使用的变量的主内存副本拷贝，线程对变量的所有操作（读取，赋值等）都必须在工作内存中进行，而不能直接读写主内存的变量，这里的变量指的是实例字段，静态字段和构成数组对象的元素，而不包括线程私有的局部变量和方法参数

JMM可见性

volatile关键字可以保证变量对所有线程的可见性，可见性指一个线程修改了变量的值，新的值立刻同步到主内存中，而其他线程读取这个变量的时候，也会从主内存中拉取最新的值

volatile的特性得益于先行发生原则，先行发生原则指两个事件的结果之间的关系，如果一个事件A发生在另一个事件B之前，事件A产生的影响能被B观察到

volatile只保证可见性，不保证原子性，如果定义100个线程，它们执行循环100次的count++，count最终值不一定是10000，因为count++这个操作并不是原子性的，可能发生这种情况：线程A读取变量count，此时count值为0，然后线程B读取count为0并执行+1操作，写回到主内存，然后线程A再执行+1操作，写回到主内存，则主内存的count的值为1而不是理想的2

volatile适用于以下场景：

运行结果不依赖当前值（count=count+1不行，count=t可以），或者能够确保只有单一线程修改变量的值
变量不需要与其他状态变量共同参与不变约束

volatile第二个语义是禁止指令重排优化，这样可以避免由于指令重排而导致的错误

volatile底层禁止指令重排是通过内存屏障来实现的，内存屏障用于实现对内存操作的顺序限制

总结：

工作内存中，每次使用volatile的变量时都必须先从主内存刷新最新的值
工作内存中，每次修改volatile的变量时都必须立即同步回主内存中
volatile的关键字不会被指令重排序优化，确保代码的执行顺序与程序相同

锁优化

自旋锁：
互斥同步对性能最大的影响是阻塞的实现，挂起线程和恢复线程的操作都需要转入内核态完成，这些操作给系统的并发性能带来很大的压力
如果物理机器上有一个以上的处理器，能让两个或以上的线程同时并行执行，我们就可以让后面请求锁的那个线程稍等一下，但不放弃处理器的执行时间，看看持有锁的线程是否很快就释放锁。为了让线程等待，我们只需让线程执行一个忙循环（自旋），这项技术就是所谓的自旋锁

锁消除：
对加了同步代码但实际上不存在共享数据竞争的锁消除

锁粗化：
一串零碎的操作都对同一个对象加锁，则把加锁的范围扩展到整个操作序列的外部（如循环体内一直加锁，直接把加锁操作放到循环体之外）

轻量级锁：
无竞争的情况下使用CAS操作避免互斥量的开销

偏向锁：
无竞争的情况下把整个同步都消除

导致OOM异常

-XX:+HeapDumpOnOutOfMemory

堆溢出
方法区溢出，常量池溢出
栈中如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常
如果虚拟机在扩展栈时无法申请到足够的内存空间，则抛出OutOfMemoryError异常

内存泄露和内存溢出

内存溢出out of memory：程序申请内存时，没有足够的内存空间供其使用，出现OOM
内存泄露memory leak：程序在申请内存后，无法释放已申请的内存空间（ThreadLocalMap的生命周期跟Thread是一样的，如果没有手动删除对应key就会导致内存泄漏，所以必须手动remove()）

永久代与方法区

永久代是JDK 7之前的概念，是JVM规范里运行时数据区的一个组成部分，主要存储class，运行时常量池，字段，方法，代码，JIT代码等，它的具体实现一般为永久代，在JDK 8之后取消永久代，而使用metaspace来实现，它与永久代的区别是：它不是在堆内存中的，而是在本地内存中，-XX:MaxMetaspaceSize可以设置元空间大小

OS（持续更新）

发表于 2019-09-01 | 分类于面经 | 阅读次数:

进程，线程和程序以及它们的区别

进程：进程是进程实体的运行过程，是系统进行资源分配和调度的一个独立单位
线程：是进程的实体，是CPU调度和分派的基本单位，比进程更小的能独立运行的基本单位

进程和线程的区别

调度的基本单位：线程是调度和分派的基本单位，进程是资源分配的最小单位
资源：进程可以拥有资源，并作为系统中拥有资源的一个基本单位，线程本身不拥有系统资源，而是仅有一点保证独立运行的资源，线程还允许多个线程共享该进程所拥有的资源
独立性：同一进程的不同线程之间的独立性要比不同进程的独立性低，线程往往是为了提高并发性和进行相互之间的合作而创建的，它们共享进程的内存地址空间和资源
系统开销：OS为进程的调度，创建和撤销的开销很大，需要OS内核的干预，而线程开销则小很多

阻塞，挂起和睡眠

挂起：主动，由系统或程序发出（不释放CPU，可能释放内存，放在外存）
阻塞：被动，抢占资源中得不到资源，被动的挂起在内存，等待某种资源或信号量将他唤醒（释放CPU，不释放内存）

形象的解释：
挂起线程的意思就是你对主动对雇工说：“你睡觉去吧，用着你的时候我主动去叫你，然后接着干活”
使线程睡眠的意思就是你主动对雇工说：“你睡觉去吧，某时某刻过来报到，然后接着干活”
线程阻塞的意思就是，你突然发现，你的雇工不知道在什么时候没经过你允许，自己睡觉呢，但是你不能怪雇工，肯定你这个雇主没注意，本来你让雇工扫地，结果扫帚被偷了或被邻居家借去了，你又没让雇工继续干别的活，他就只好睡觉了。至于扫帚回来后，雇工会不会知道，会不会继续干活，你不用担心，雇工一旦发现扫帚回来了，他就会自己去干活的。因为雇工受过良好的培训。这个培训机构就是操作系统

挂起状态涉及中级调度，当内存中某个程序需要大的内存空间来执行，但这时内存没有空余空间了，OS就会根据调度算法把一些进程放到外存中

并发与并行

并发指多个时间同一时刻发生，并行指多个时间同一时间间隔发生
并发同一时刻只有一条指令执行，但多个进程指令快速轮流执行，使得宏观上具有多个进程同时执行的效果，但微观上并不是同时执行，并行无论宏观和微观都是同时执行
多处理器系统中可以存在并发和并行，而单处理器系统只能有并发

中断和轮询

轮询：系统对I/O轮流询问一遍有无处理要求，询问后有要求的，则加以处理
中断：指CPU在正常运行程序的过程中，由于预先安排或发生了各种随机的内部或外部事件，使CPU中断正在运行的程序，而转到为响应的服务程序去处理

同步和异步，阻塞和非阻塞

同步和异步：

它们关注的是消息通信机制
所谓同步，就是发出一个调用时，该进程就一直等待接收响应，直到调用返回，取得返回值
而异步则是调用在发出之后，调用者不需要等待响应，可以继续做其他事，或者主动挂起线程释放CPU

阻塞和非阻塞：

它们关注的是程序在等待调用结果（消息，返回值）时的状态
阻塞：调用结果返回之前，调用者会被挂起，直到得到结果才继续
非阻塞：调用者调用后，不会处于阻塞状态，而是继续运行

什么是线程安全

当多个线程访问某段代码时，无论通过怎样的调用或者这些线程如何交替执行，在主程序不需要做任何的同步的情况下，多次执行的结果一致且是我们设想的正确结果，或者说和单线程环境执行的结果一致，那么这段代码就是线程安全的

临界区，解决冲突

互斥访问：两个进程不能同时进入同一组共享变量的临界区域
临界资源：各进程采取互斥访问方式实现共享的资源称为临界资源
临界区：每个进程中访问临界资源的那段代码称为临界区

空闲让进：无进程处于临界区，表明临界资源空闲，允许一个请求进入临界区的进程进入自己的临界区
忙则等待：已有进程进入临界区，其他试图进入临界区的进程必须等待
有限等待：对要求访问临界资源的进程，应保证在有限时间内能进入自己的临界区，以免陷入死等状态
让权等待：当进程不能进入自己的临界区时，应立即释放处理机，防止进程陷入忙等状态

分段和分页

（仅仅是概念，对分页和分段还需要去了解访问内存次数，地址变换机构，快表）

分页：分页主要是将用户程序的地址空间划分为若干个固定大小的区域，称为”页”或”页面”，典型的页面大小为1kb，相应地，也将内存空间分为若干个物理块或页框，页和块的大小相同，这样可以将用户程序的任一页放入任一物理块中，实现离散分配
分页是为实现离散分配方式，以消减内存的外零头，提高内存的利用率；或者说，分页仅仅是由于系统管理的需要，而不是用户的需要

分段：按程序的逻辑结构，将程序的地址空间划分为若干段，各段大小可不相同，在进行存储分配时，以段为单位，这些段在内存中可以不相邻接
为什么引入：一方面程序可分为若干个段，主程序段，子程序段A，子程序段B，数据段，栈段等，另一方面实现和满足信息共享，信息保护，动态链接以及信息的动态增长等需要

段页区别：

页是信息的物理单位，段是逻辑单位
页长度固定由系统决定，段长度不固定
分页用户程序地址空间是一维的，分段是二维的，既要给出段名又要给出段内地址

进程同步方法

我们把异步环境下的一组并发进程因直接制约而互相发送消息、进行互相合作、互相等待，使得各进程按一定的速度执行的过程称为进程间的同步

原子操作：不会被线程调度机制打断的操作
信号量机制：P,V原语
自旋锁：互斥同步时，对性能影响最大的是阻塞（挂起和恢复线程要进入内核态完成），引入自旋锁，让后面请求锁的线程”稍等一下”，但不放弃处理机的执行时间，即执行一个忙循环（自旋），看看持有锁的对象是否很快就释放锁
管程：管程是由局部于管程自己的若干公共变量及其说明和所有访问这些公共变量的过程所组成的软件模块

进程间通信

管道：半双工通信，只能在具有亲缘关系的进程间使用
命名管道：允许无亲缘关系
消息队列
共享内存
信号量
套接字

管道

netstat -tulnp | grep 8080 ：把netstat -tulnp的输出作为grep 8080的输入，竖线是匿名管道，管道通信是单向的

命名管道：
mkfifo test ：生成一条test命名管道
echo "this is a pipe" > test 往这条管道写数据
cat < test ：读数据

管道的通知机制类似于缓存，把数据放到某个缓存区域，等另一个线程去取，单向传输，缺点是效率低，a进程给b进程传输数据，只能等b进程取数据之后a进程才能返回，不适合频繁通信的进程，优点是简单，保证数据能够被取走

消息队列

aa进程要给b进程发送消息，只需要把消息放在对应队列即可，b进程需要的时候直接从对应消息队列取出

优点是进程往消息队列放消息后就可以返回，缺点是如果发送的数据占用内存较大，通信特别频繁，会导致发送消息（拷贝）的过程需要花很多时间

共享内存

可以让通信的2个进程各自取出1块虚拟地址空间映射到相同的物理内存，这样就实现了共享内存的机制，发送消息的时间也不存在了

信号量

共享内存可能导致多进程竞争内存的问题，使用信号量来解决即可（内存的互斥访问）

Socket

远程主机的不同进程之间的通信使用Socket

Linux文件属性

十位，- — — —，第一个是文件类型标识符，-表示普通文件，c表示字符设备，b表示块设备，d表示目录，l表示链接文件，第一组—表示用户权限位，第二组表示组权限位，第三组表示其他权限位，—分别表示rwx权限

死锁

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁

产生死锁的必要条件：

互斥条件：一个资源每次只能被一个进程使用
请求和保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放
不可抢占条件：进程已获得的资源，在未使用完之前不能强行剥夺
循环等待条件：若干进程之间形成一种首尾相接的循环等待资源关系

处理死锁：

预防死锁：破坏产生死锁的后3个必要条件，比如资源一次性分配，新请求不能满足就释放已有资源，资源有序分配等
避免死锁：它与预防不一样，它不是事先采取限制措施的方法破坏产生死锁的必要条件，它允许进程动态申请资源，但系统在进行资源分配前，应先计算此次资源分配的安全性，若安全才分配，否则令进程等待，常见的安全性算法是银行家算法
检测死锁：资源分配图，死锁定理（化简资源分配图，不可完全简化就死锁）
解除死锁

生产者-消费者问题

假定生产者和消费者之间的公用缓冲池具有n个缓冲区，此时可利用互斥信号量mutex实现诸进程对缓冲池的互斥利用；利用信号量empty和full分别表示缓冲池中空缓冲区和满缓冲区的数量，只要还有空缓冲区，生产者就可以往里面写消息，满缓冲区同理

int in = 0, out = 0;
item buffer[n];
semaphore mutex = 1, empty = n, full = 0;

void producer() {
    do {
        produce an item nextp;
        ...
        wait(empty);
        wait(mutex);
        buffer[in] = nextp;
        in = (in + 1) % n;
        signal(mutex);
        signal(full);
    } while (TRUE);
}

void consumer() {
    do {
        wait(full);
        wait(mutex);
        nextc = buffer[out];
        out = (out + 1) % n;
        signal(mutex);
        signal(empty);
        consume the item in nextc;
        ...
    } while (TRUE);
}

void main() {
    cobegin
        producer(); consumer();
    coend
}

每个程序的多个wait操作顺序不能颠倒，必须要先执行对资源信号量的wait操作，然后再执行对互斥信号量的wait操作，否则可能引起死锁（如在生产者中，如果先申请缓冲池，然后再申请空池，但空池此时数量为0，则生产者会因为持有缓冲池但没有空池而进入死锁）

生产者消费者模型的作用是什么

通过平衡生产者的生产能力和消费者的消费能力来提升整个系统的运行效率，这是生产者消费者模型最重要的作用
解耦，这是生产者消费者模型附带的作用，解耦意味着生产者和消费者之间的联系少，联系越少越可以独自发展而不需要收到相互的制约

哲学家进餐问题

要把5只筷子定义为5个初值为1信号量（而不是一个初值为5的信号量，因为筷子位置不同，5个哲学家只能拿自己左右的筷子，而不是任意拿筷子）

解决方法可以有：

最多只允许4个哲学家同时去拿左边的筷子
仅当哲学家左右两只筷子均可用时，才允许他拿起筷子
规定奇数号哲学家先拿他左边的筷子，再拿右边的筷子，偶数号哲学家则相反

读者-写者问题

读写互斥wmutex，rmutex对临界资源readcount的互斥访问

semaphore rmutex = 1, wmutex = 1;
int readcount = 0;

void reader() {
    do {
        wait(rmutex); // 对readcount互斥访问
        if (readcount == 0) wait(wmutex);
        readcount++;
        signal(rmutex);
        ...
        perform read operation;
        ...
        wait(rmutex);
        readcount--;
        if (readcount == 0) signal(wmutex);
        signal(rmutex);
    } while (TRUE);
}

void writer() {
    do {
        wait(wmutex);
        perform write operation;
        signal(wmutex);
    } while (TRUE);
}

void main() {
    cobegin
        reader(); writer();
    coend
}

独木桥问题

对于东西两侧的车，桥是一个互斥资源，而对东西两侧各自而言，每辆车上桥是同步关系

// 分别表示独木桥，东侧车辆，西侧车辆在桥上数量
semaphore mutex = 1, east = 1, west = 1
int countE = 0, countW = 0;

cobegin
process PEast() {
    P(east);
    if (countE == 0) P(mutex);
    countE++;
    V(east)
    // 过桥
    P(east);
    countE--;
    if (countE == 0) V(mutex);
    V(east);
}

process PWest() {
    P(west);
    if (countW == 0) P(mutex);
    countW++;
    V(west);
    // 过桥
    P(west);
    countW--;
    if (countW == 0) V(mutex);
    V(west);
}

进程调度策略

先来先服务，短作业优先，优先级，时间片轮转，多级反馈

多级反馈指设置多个就绪队列，每个队列优先级不同（从第一个到最后一个依次降低），为不同队列中的进程赋予的执行时间片的大小也各不相同，优先级越高的队列时间片越小，每个队列按先来先服务调度，队列间按优先级调度，高优先级的队列非空，低优先级的队列就无法被调度

两个互为存在的条件

并发和共享是 os 的两个最基本的特征,又互为存在的条件

MySQL（持续更新）

发表于 2019-09-01 | 分类于面经 | 阅读次数:

三个范式

满足第三范式必定满足第二范式，满足第二范式必定满足第一范式
第一范式：字段是最小的单元，不可再分

学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的

第二范式：满足第一范式，表中的字段必须完全依赖于全部主键而非部分主键

其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的
学号为1024的同学，姓名为Java3y，年龄是22岁。姓名和年龄字段都依赖着学号主键。

第三范式：满足第二范式，非主键外的所有字段必须互不依赖

就是数据只在一个地方存储，不重复出现在多张表中，可以认为就是消除传递依赖
比如，我们大学分了很多系（中文系、英语系、计算机系……），这个系别管理表信息有以下字段组成：系编号，系主任，系简介，系架构。那我们能不能在学生信息表添加系编号，系主任，系简介，系架构字段呢？不行的，因为这样就冗余了，非主键外的字段形成了依赖关系(依赖到学生信息表了)！正确的做法是：学生表就只能增加一个系编号字段。

什么是视图？视图的使用场景有哪些？

视图是一种基于数据表的虚表
视图建立在已有表的基础上，视图赖以建立的表称为基表
向视图提供数据内容的语句为SELECT语句，可以将视图理解为存储起来的SELECT语句
视图向用户提供基表数据的另一种表现形式
视图没有存储真正的数据，真正的数据还是存储在基表中
程序员操作的虽然是视图，但最终还是会转换成操作基表
一个基表可以有0个或多个视图

视图的作用：
视图主要用于把用户想要看到的数据展示给用户，而用户不需要的数据则不展示给他们看
视图是基于查询的虚表，可以将查询出来的数据进行封装，在使用的时候会很方便，但不提高查询效率

创建视图 CREATE VIEW test_view_1 AS SELECT name FROM user
查询视图 SELECT * FROM test_view_1
创建视图并指定视图字段名 CREATE VIEW test_view_2(username) AS SELECT name FROM user

drop，delete和truncate分别在什么场景使用

drop table

属于DDL
不可回滚
不可带where
表内容和结构删除
删除速度快

truncate table

属于DDL
不可回滚
不可带where
表内容删除
删除速度快

delete from

属于DML
可回滚
可带where
表结构在，表内容根据where执行情况而定
删除速度慢，需要逐行删除

不再需要一张表的时候，用drop
想保留部分数据行的时候，用delete，并且带上where
保留表删除所有数据用truncate

索引是什么？有什么作用与优缺点？

什么是索引？

是一种快速查询表中内容的机制，类似于新华字典的目录
运用在表中某些字段上，但存储时，独立于表外

InnoDB的聚集索引使用B+树实现，叶节点存放整张表的行记录数据（称为数据页），B+树叶结点包含信息，非叶结点只起索引作用（非叶结点的值是主键，两个值A和B之间的子树内所有值大小不大于B，不小于A）
辅助索引（非聚集索引）叶子节点不包含行记录的全部数据，它的索引行中还额外包含一个书签，用于告诉InnoDB哪里可以找到与索引相对应的行数据，查询语句中如果条件满足辅助索引，但查询列不在辅助索引，则通过辅助索引找到对应行后，需要使用这个书签回表查询该行记录的其他列（非叶结点的值是索引列，两个值A和B之间的子树内所有值大小不大于B，不小于A）

覆盖索引：一个查询语句的执行只要从索引中就能取得，不必从数据表中读取（只要查询列在辅助索引，就不需要回表查询，只要查询1次即可）

CREATE INDEX index_name ON table_name (column_name)

表的数据行实际上存放在聚簇索引的叶子页中

索引的使用场合：

表经常SELECT操作
表很大，记录内容分布范围很广
列名经常在WHERE子句或连接条件中出现

不建议使用索引的场合

表经常进行INSERT/UPDATE/DELETE操作
表很小
列名不经常在WHERE子句或连接条件中出现

优缺点：

索引加快数据库的检索速度
索引降低了插入，删除，修改等维护任务的速度
索引要占用物理和数据空间

索引分类

唯一索引，主键索引，聚集索引，非聚集索引

最左匹配原则

创建索引考虑哪些因素？
查询概率比较高，经常作为where条件的字段设置索引

创建多列索引，where子句中使用最频繁的一列放在最左边，MySQL查询索引会遵循最左前缀匹配原则，检索数据时从最左边

底层就是把索引拼凑在一起，然后插入到B+树中

什么是事务

事务：一个事务中所进行的所有操作，要么同时成功，要么同时失败

事务符合ACID特性：

原子性：整个事务操作为原子操作
一致性：事务将数据库从一种状态转变为下一种一致的状态，完整性约束没有被破坏
隔离性：每个读写事务的对象对其他事务的操作对象能互相分离，即提交前的事务对其他事务都不可见
持久性：事务一旦提交，其结果是永久性的

原子性关注状态，要么全部成功要么全部失败
一致性关注的是数据的可见性，中间状态不可见，最初和最终状态对外可见，且必须符合数据完整性约束（转账的例子）

比如有A有500块存款，B有500块存款，A转200给B，则一致性操作如下：
A-200;B+200
如果这两条操作都执行完毕，那同时它也是原子性的
如果操作变为A-200;B+100，且都完成了，那这个操作是原子性的，但不是一致性的

事务隔离级别

READ UNCOMMITTED 未提交读：
READ COMMITTED 提交读：
REPEATABLE READ 不可重复读：
SERIALIZABLE 串行化：

InnoDB默认事务隔离级别是REPEATABLE READ，并且添加了next-key lock算法避免幻读

事务隔离级别	脏读	不可重复读	幻读	加锁读
READ UNCOMMITTED 未提交读	√	√	√	×
READ COMMITTED 提交读	×	√	√	×
REPEATABLE READ 可重复读	×	×	√	×
SERIALIZABLE 串行化	×	×	×	√

脏读：一个事务读到另一个事务未提交的数据
不可重复读：一个事务(还没COMMIT)读取到另一个事务已经提交(COMMIT)的数据，即一个事务可以看到其他事务所做的修改
幻读：一个事务内读取到别的事务插入(或删除)的数据，导致前后读取不一致（幻读出现的前提是并发的事务中有事务发生了插入，删除操作）

不可重复读的重点是修改:
同样的条件, 你读取过的数据, 再次读取出来发现值不一样了
幻读的重点在于新增或者删除
同样的条件, 第1次和第2次读出来的记录数不一样

对于不可重复读，只需要锁住满足条件的记录，而对于幻读，则需要锁住满足条件及其相近的记录

哈希索引和B+树索引的区别

哈希索引使用哈希表，等值查询速度快，但不支持范围查询，也没有办法利用索引完成排序，不支持多列索引的最左匹配原则，大量重复键的时候，存在哈希碰撞，效率很低

MySQL锁

lock锁事务，latch锁线程（轻量级）

行级锁：
共享锁（S Lock）：允许事务读一行数据
排他锁（X Lock）：允许事务删除或更新一行数据

只有共享锁与共享锁之间才兼容

意向锁：
为了支持在不同粒度上进行加锁操作，InnoDB支持一种额外的锁方式，称为意向锁

如果要给最下层即最细粒度的对象上锁，就要先对粗粒度对象上锁，如：对记录r上X锁，要先对数据库A，表，页上意向锁IX，最后对记录r上X锁

InnoDB的意向锁是表级的锁，设计目的是为了在一个事务中揭示下一行江北请求的锁的类型，支持意向排他锁(IS Lock)和意向共享锁(IX Lock)

一致性非锁定读

一致性非锁定读指InnoDB存储引擎通过多版本控制的方式来读取当前执行时间数据库中行的数据。如果读取的行正在执行DELETE或UPDATE操作，这时读操作不会因此去等待行上锁的释放，相反，InnoDB存储引擎会去读取行的一个快照（undo段的快照数据），非锁定读不会占用和等待表上的锁

READ COMMITTED和REPEATABLE READ下，InnoDB使用一致性非锁定读，区别是READ COMMITTED下的快照数据是锁定行的最新一份快照数据，REPEATABLE READ下的快照数据是本事务开始时的行数据版本

一致性锁定读

SELECT ... FOR UPDATE; 对读取的行记录加X锁
SELECT ... LOCK IN SHARE MODE; 对读取的行记录加S锁

Next-Key Lock

Next-Key Lock会锁住一个范围包括记录本身，可以解决幻读的问题
比如：一个索引有10,11,13和20这四个值，则该索引可能被Next-Key Locking锁住的范围：(-∞,10],(10,11],(11,13],(13,20],(20,+∞)
当查询的索引含有唯一属性时，InnoDB存储引擎会对Next-Key Lock进行优化，将其降级为Record Lock（只锁住行记录本身）

看下面例子：

CREATE TABLE z (a INT, b INT, PRIMARY KEY(a), KEY(b));
INSERT INTO z SELECT 1,1;
INSERT INTO z SELECT 3,1;
INSERT INTO z SELECT 5,3;
INSERT INTO z SELECT 7,6;
INSERT INTO z SELECT 10,8;

当执行SELECT * FROM z WHERE b=3 FOR UPDATE，需要对2个索引分别加锁，聚集索引仅加上值为5的记录锁，而辅助索引会加上(1,3]的锁，同时，InnoDB会对辅助索引的下一个键值加上gap lock(只锁范围，不包括本身)，即在辅助索引加上(3,6)的锁，此时在辅助索引上，就加上了(1,6)的锁，而聚集索引只加上了值为5的锁

乐观锁与悲观锁

悲观锁：总是假设最坏的情况，每次去拿数据都认为别人会修改，所以每次取数据都会上锁
SELECT * FROM table WHERE condition FOR UPDATE;
SELECT * FROM table WHERE condition LOCK IN SHARE MODE;

乐观锁：总是假设最好的情况，每次取取数据都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现
通常实现步骤是这样的：表中进行数据操作时(更新)，先给数据表加一个版本(version)字段，每操作一次，将那条记录的版本号加1，每次查询那条记录，就获取version字段，如果要对记录进行操作，就判断此刻的version是否与刚刚查询出来的version一致，如果一致则说明此时没有其他程序对其操作，则可以更新，如果不一致则不更新
UPDATE table SET num=num-1 WHERE id=10 and version=23

悲观锁用于多写场合，乐观锁用于多读场合

超键，候选键，主键，外键的概念

超键：关系中唯一标识元组的属性集称为关系模式的超键，超键包含候选键和主键
候选键：最小超键，没有冗余元素的超键
主键：数据库表中对储存数据对象予以唯一和完整标识的数据列或属性的组合。一个数据列只能有一个主键，且主键的取值不能为null
外键：在一个表中存在的另一个表的主键称为此表的外键

e.g. 邮寄地址（城市名，街道名，邮政编码，单位名，收件人）

超键：{城市名，街道名}，{街道名，邮政编码}，{城市名，街道名，邮政编码}，{城市名，街道名，邮政编码，单位名}等唯一标识元组的属性集
候选键：{城市名，街道名}和{街道名，邮政编码}
如果选取{城市名，街道名}作为唯一标识实体的属性，那么它就是主键

SQL约束有哪几种

NOT NULL
UNIQUE
PRIMARY KEY
FOREIGN KEY
CHECK

MySQL存储引擎

InnoDB:提供对数据库ACID事务的支持，提供行级锁和外键的约束
MyIASM：不支持事务，不支持行级锁和外键
MEMORY：所有数据都在内存中，数据处理速度快，但安全性不高

如果一个表修改要求比较高的事务处理，可以选择InnoDB。这个数据库中可以将查询要求比较高的表选择MyISAM存储。如果该数据库需要一个用于查询的临时表，可以选择MEMORY存储引擎

MyISAM和InnoDB区别

InnoDB支持事务
InnoDB支持外键
InnoDB是聚集索引，实际数据存放在主键索引的叶子节点上，而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针
MyISAM用一个变量保存整个表的行数，SELECT COUNT(*) FROM TABLE不需要全表扫描
InnoDB最小的锁粒度是行锁，MyISAM是表锁

MyIASM和InnoDB使使用的索引的数据结构是什么

都是B+树
MyIASM B+树的数据结构中存储的内容实际上是实际数据的地址值
InnoDB B+树中数据结构存储的都是实际的数据

varchar和char的区别

char固定长度，填充空格（但取数据时会自动去除空格），varchar可变长度，参数指定的是最大长度，存储效率没有char高

mysql有关权限的表

user权限表：记录允许连接到服务器的用户账号信息，里面的权限是全局级的
db权限表：记录各个账号在各个数据库上的操作权限
table_priv权限表：记录数据表级的操作权限
columns_priv：记录数据列级的操作权限
host权限表：配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响

mysql给离散度低的字段建立索引会出现什么问题，具体说下原因

重复性较强的字段，不适合添加索引，比如性别，这样查询反而更慢
索引是把一个或几个字段按规律排列，然后加上该字段所在行的数据的物理地址
访问索引需要额外的IO开销，从索引中拿到的只是地址，如果建立离散度低的索引，比如100万行数据，一次索引定位能拿到50万行，访问完这50万行的索引后，再进行50万次访问表，IO开销就十分大，如果离散度高，则一次索引访问后只剩下几行数据，就十分值得

数据库系统的组成

硬件平台及数据库：大内存，大硬盘
软件：
- 数据库管理系统：为数据库建立，使用和维护配置的系统软件
- OS
- 与数据库接口的高级语言及其编译系统
- 数据库应用系统
人员：
- 数据库管理员
- 系统分析员和数据库设计人员
- 应用程序员
- 用户

存储过程优点

允许模块化程序设计
不需要像解释执行的SQL语句那样在提出请求时才进行语法分析和优化工作，运行效率高
降低客户机和服务器之间的通信量，客户机的应用程序只要通过网络向服务器发出调用存储过程的名字和参数即可
安全性：没有权限执行存储过程的用户，也可授权他们执行存储过程

SQL语句HAVINT与WHERE

WHERE语句在GROUP BY语句之前；SQL会在分组之前计算WHERE语句。
HAVING语句在GROUP BY语句之后；SQL会在分组之后计算HAVING语句。

通配符

%：替代0个或多个字符
_：替代一个字符
[charlist]：字符列中任何单一字符
[^charlist]或[!charlist]：不在字符列中的任何单一字符

SQL语句没有时插入有则更新

INSERT INTO 表名(字段) VALUES ON DUPLICATE KEY UPDATE 字段名=值

慢查询分析

MySQL提供慢查询日志，日志会记录所有执行时间超过long_query_time（默认10s）的SQL及相关信息

SHOW VARIABLES LIKE 'long_query_time'; ：慢查询时间
SHOW VARIABLES LIKE 'slow_query_log'; ：查看慢查询日志是否开启
SHOW VARIABLES LIKE 'slow_query_log_file'; ：查看慢查询日志的位置

在MySQL的配置文件my.cnf的[mysqld]项下可以配置慢查询日志

[mysqld]
slow_query_low=1
slow_query_log_file=/dir/xxx.log
long_query_time=2

分析： explain select xxx ...
explain出现的分析结果如下：

type列：连接类型，一个好的SQL语句至少达到range级别，杜绝出现all级别，（还有const级别，const是常数，比如 SELECT * FROM actor WHERE id = 1）
key列：使用到的索引名，如果没有选择索引，值是NULL
key_len列：索引长度
rows列：扫描行数，是个预估值
extra列：详细说明，常见不太友好的有：Using filesort,Using temporary

慢查询优化

最左前缀匹配原则：mysql会一致向右匹配直到遇到范围查询(>,<,between,like)就停止匹配，因此如果建立(a,b,c,d)的索引，查询的时候是a=1 and b=2 and c>3 and d=4，d是用不到索引的
=和in可以乱序，MySQL的查询优化器会优化，IN包含值不应过多（IN做了优化，是使用数组排序，如果数值较多，消耗也大，对于连续的比如IN (1,2,3)，可以使用BETWEEN就使用它）
尽量选择区分度高的列作为索引，区分度公式：count(distinct col)/count(*)，比例越大，扫描的记录数越少，唯一键的区分度是1
索引列不能参与计算，保持列”干净”
尽量扩展索引，不要新建索引。如表中已有a索引，要加(a,b)索引，只需要修改原来的索引即可
当只需要一条数据，使用limit 1
SELECT指明字段名，如果SELECT *，会造成很多不必要的消耗

个人感觉面试的时候上面的够了，如果还不够这里还有一些

ER图

实体-联系图，表示实体类型，属性和联系的方法，用来描述现实世界的概念模型

正方形内是实体类型，圆形内是属性，主属性名称有下划线，菱形是联系，两个实体之间有1对N，1对1，N对M的关系

MakaLoo

Beautifully struggle every day

GitHub 知乎 E-Mail

Spring Boot日志

SLF4j使用

遗留问题

Spring Boot日志关系

日志的使用

指定配置

切换日志框架

Spring Boot入门与配置

简介

优点

微服务

Hello World

相关依赖

@SpringBootApplication

@RestController

配置文件

YAML语法

为bean的属性配置值

使用yml为属性配置值

使用@Value为属性配置值

两个配置的区别

@PropertySource

@ImportResource

@Bean装载bean

@Bean与@Component的区别

yml(properties)配置文件的占位符

Profile

配置文件的加载位置

Conditional

自动配置原理

Java IO

框架

File对象

基本类型数据流

字符流与字节流的转换

HeadFirst设计模式-观察者模式

案例分析

初步设计方案

遇到问题

解决方案

本章总结-观察者模式

Java内置的观察者模式

HeadFirst设计模式-入门&策略模式

案例分析

初步设计方案

遇到问题

解决方案

本章总结

设计模式（持续更新）

策略模式

缺点

使用

观察者模式

使用

装饰者模式

使用

工厂模式

简单工厂模式

使用

抽象工厂模式

使用

工厂与抽象工厂的区别

单例模式

命令模式

适配器模式与外观模式

模板方法模式

迭代器与组合模式

状态模式

代理模式

设计原则

其他

正则表达式

JSON

JVM

JVM组成

JVM内存模型

对象创建步骤

Java对象结构

Java对象定位方式

堆内的分区