枫叶的小博客

本章是整理知识内容，为强化知识长期更新。

Spring

• Spring是一个轻量级的IoC和AOP容器框架。是为Java应用程序提供基础性服务的一套框架，目的是用于简化企业应用程序的开发，它使得开发者只需要关心业务需求。

• 主要由以下几个模块组成：

  • Spring Core：核心类库，提供IOC服务
  • Spring Context：提供框架式的Bean访问方式，以及企业级功能（JNDI、定时任务等）
  • Spring AOP：AOP服务切面编程
  • Spring DAO：对JDBC的抽象，简化了数据访问异常的处理
  • Spring ORM：对现有的ORM框架的支持
  • Spring Web：提供了基本的面向Web的综合特性，例如多方文件上传
  • Spring MVC：提供面向Web应用的Model-View-Controller实现

• IoC（Inversion of Control，翻译为“控制反转”）不是一个具体的技术，而是一种设计思想。与传统控制流相比，IoC 会颠倒控制流，在传统的编程中需要开发者自行创建并销毁对象，而在 IoC 中会把这些操作交给框架来处理，这样开发者就不用关注具体的实现细节了，拿来直接用就可以了，这就是控制反转。

• IoC 很好的体现出了面向对象的设计法则之一——好莱坞法则：“别找我们，我们找你”。即由 IoC 容器帮对象找到相应的依赖对象并注入，而不是由对象主动去找。

• DI（Dependency Injection，翻译为“依赖注入”）表示组件间的依赖关系交由容器在运行期自动生成，也就是说，由容器动态的将某个依赖关系注入到组件之中，这样就能提升组件的重用频率。通过依赖注入机制，我们只需要通过简单的配置，就可指定目标需要的资源，完成自身的业务逻辑，而不需要关心资源来自哪里、由谁实现等问题。

• IoC 和 DI 其实是同一个概念从不同角度的描述的，由于控制反转这个概念比较含糊（可能只理解成了容器控制对象这一个层面，很难让人想到谁来维护对象关系），所以 2004 年被开发者尊称为“教父”的 Martin Fowler（世界顶级专家，敏捷开发方法的创始人之一）又给出了一个新的名字“依赖注入”，相对 IoC 而言，“依赖注入”明确描述了“被注入对象依赖 IoC 容器配置依赖对象”。

依赖注入

• 平常的Java开发中，程序员在某个类中需要依赖其它类的方法。通常是new一个依赖类再调用类实例的方法，这种开发存在的问题是new的类实例不好统一管理。 Spring提出了依赖注入的思想，即依赖类不由程序员实例化，而是通过Spring容器帮我们new指定实例并且将实例注入到需要该对象的类中。依赖注入的另一种说法是”控制反转”。通俗的理解是：平常我们new一个实例，这个实例的控制权是我们程序员。而控制反转是指new实例工作不由我们程序员来做而是交给Spring容器来做。
• IOC对于Spring框架来说，就是由Spring来负责控制对象的生命周期和对象间的关系。
• 所谓依赖注入，就是由IOC容器在运行期间，动态地将某种依赖关系注入到对象之中，所以，以来注入DI 和控制反转IOC 是从不同的角度描述的同一间事情，就是值通过引用IOC容器，利用以来关系注入的方式，实现对象之间的解耦。

注入方式

• Set注入。
• 构造方法注入。
• 工厂的方法注入。
• 通过属性注入。
• 通过List注入。
• 通过Map注入。

Spring AOP

• AOP(Aspect-Oriented Programming:⾯向切⾯编程)能够将那些与业务⽆关，却为业务模块所共同调⽤的逻辑或责任（例如事务处理、⽇志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。

  • Spring AOP就是基于动态代理的，如果要代理的对象，实现了某个接⼝，那么Spring AOP会使⽤JDK Proxy，去创建代理对象，⽽对于没有实现接⼝的对象，就⽆法使⽤ JDK Proxy 去进⾏代理了，这时候Spring AOP会使⽤Cglib ，这时候Spring AOP会使⽤ Cglib ⽣成⼀个被代理对象的⼦类来作为代理。

  

  • Spring Aop是运行时增强。
  • Cglib Aop是编译器增强。

• AOP专门用于处理系统中分布于各个模块中交叉关注点的问题，在JavaEE应用中，常常通过AOP来处理一些横切性质的系统级服务，如事物管理、安全检查、缓存对象池管理。

  • 1.）切面 -Aspect 切面类 比如日志类
  • 2.） 连接点 - Join Point 加入切点的那个点
  • 3.）通知 -Advice 是在切面某个特定的连接点上的动作。
  • 4.）切入点 - Point Cut 匹配连接点的断点
  • 5.）引入 - Introduction
  • 6.）目标对象 - Target Object 被一个或多个通知对象，永远被代理的对象。
  • 7.） AOP代理 - AOP Proxy AOP创建的对象用来实现切面对象。
  • 8.）织入 - Weaving
  • 9.）AOP通俗的理解：
    • 一个组建A，不关心其他常用的服务组件B，但是这个组件A使用组件B的时候不是组建A自身去调用，而是通过配置等其他方式，比如Spring中可以通过XML配置文件。这样就使的A压根不需要知道服务组件B是怎么样的，A只关心自己的业务逻辑，具体A使用B的时候，配置文件去做，与具体的A组件无关。

Spring框架中的设计模式

• 工厂模式：BeanFactory就是简单工厂模式的体现，用来创建对象的实例
• 单例模式：Bean默认为单例模式
• 代理模式：Spring的AOP功能用到了JDK的动态代理和CGLIB字节码生成技术
• 模板方法：用来解决代码重复的问题。比如. RestTemplate, JmsTemplate, JpaTemplate
• 观察者模式：定义对象键一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知被制动更新，如Spring中listener的实现–ApplicationListener，Spring 事件驱动模型就是观察者模式很经典的⼀个应⽤。
• 适配器模式 :Spring AOP 的增强或通知(Advice)使⽤到了适配器模式、spring MVC 中也是⽤到了适配器模式适配 Controller 。
• 策略模式： Bean的实例化的时候决定采用何种方式初始化bean实例（反射或者CGLIB动态字节码生成），Resource 接口是具体资源访问策略的抽象。
• 装饰器模式：Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。
• 模版模式：Spring Template 都采用了该模式。

Spring中Autowired和Resource关键字

• @Resource和@Autowired都是做bean的注入时使用，其实@Resource并不是Spring的注解，它的包是javax.annotation.Resource，需要导入，但是Spring支持该注解的注入。
• Autowired注解是按照类型（byType）装配依赖对象，默认情况下它要求依赖对象必须存在，如果允许null值，可以设置它的required属性为false。如果我们想使用按照名称（byName）来装配，可以结合@Qualififier注解一起使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class TestServiceImpl { 
  // 下面两种@Autowired只要使用一种即可 
  @Autowired 
  private UserDao userDao; // 用于字段上 
  
  @Autowired  // 用于属性的方法上
  public void setUserDao(UserDao userDao) 
  {  
    this.userDao = userDao; 
  } 
}
// @Autowired注解是按照类型（byType）装配依赖对象，默认情况下它要求依赖对象必须存在，如果允
// 许null值，可以设置它的required属性为false。如果我们想使用按照名称（byName）来装配，可以结
// 合@Qualifier注解一起使用。如下：
public class TestServiceImpl {
  @Autowired 
  @Qualifier("userDao") private UserDao userDao;
}

• Resource默认按照ByName自动注入，由J2EE提供，需要导入包javax.annotation.Resource。@Resource有两个重要的属性：name和type，而Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以，如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不制定name也不制定type属性，这时将通过反射机制使用byName自动注入策略。

1
2
3
4
5
6
7
8
9
10
11
12
13

public class TestServiceImpl { 
  // 下面两种@Resource只要使用一种即可 
  
  // 用于字段上 
  @Resource(name="userDao") 
  private UserDao userDao; 
  
  // 用于属性的setter方法上 
  @Resource(name="userDao") 
  public void setUserDao(UserDao userDao) { 
    this.userDao = userDao;
  } 
}

Bean注册方式

• XML 配置文件的注册方式

1
2
3
4

<bean id="person" class="org.springframework.beans.Person">
   <property name="id" value="1"/>
   <property name="name" value="Java"/>
</bean>

Java 注解的注册方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 可以使用 @Component 注解方式来注册 Bean
@Component
public class Person {
   private Integer id;
   private String name
   // 忽略其他方法
}

// @Bean 注解方式来注册 Bean
@Configuration
public class Person {
   @Bean
   public Person  person(){
      return new Person();
   }
   // 忽略其他方法
}

Java API 的注册方式

1
2
3
4
5
6
7
8
9
10
11
12

// 使用 BeanDefinitionRegistry.registerBeanDefinition() 方法的方式注册 Bean	
public class CustomBeanDefinitionRegistry implements BeanDefinitionRegistryPostProcessor {
	@Override
	public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
	}
	@Override
	public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException {
		RootBeanDefinition personBean = new RootBeanDefinition(Person.class);
		// 新增 Bean
		registry.registerBeanDefinition("person", personBean);
	}
}

本章属于持续学习、长期更修。

HashMap

特征

• HashMap 允许null键和null值，null键哈西值为0.
• HashMap 并不是有序的存放。在使用iterate迭代的时候，并不能得到存放顺序。
• HashMap使用它的内部类Node <K，V>来存储映射。
• HashMap将entries存储到多个单链表中，称为存储桶或存储桶。默认的箱数为16，默认负载因子0.75，它的扩展系数为2，当键值对数量大于阈值，则容量扩容到原来的2倍。
• HashMap不是线程安全的，对于多线程环境，您应该使用ConcurrentHashMap类或使用Collections.synchronizedMap()方法获取同步映射。
• 底层实现是链表，但是jdk1.8后添加了红黑谁的转换。
• HashMap的Key用存放，所以key默认不允许重复的，如果想重复就重写key的hashcode和equals方法。
• 查找方法，根据 hash 值我们能够快速定位到数组的具体下标，但是之后的话，需要顺着链表一个个比较下去才能找到我们需要的，时间复杂度取决于链表的长度，为 O(n)。为了降低这部分的开销，在 Java8 中，当链表中的元素超过了 8 个以后，会将链表转换为红黑树，在这些位置进行查找的时候可以降低时间复杂度为 O(logN)。

源码分析

HashMap中的常量以及变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

// 未指定容量大小的情况下，默认初始化16。容量都是2的幂。第一次扩容大概率情况下是64。
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
// 容量最大长个数。
static final int MAXIMUM_CAPACITY = 1 << 30;
// 默认负载因子，
static final float DEFAULT_LOAD_FACTOR = 0.75f;
// HashMap使用单链表来存储元素，这些元素称为bin或buckets。当我们调用put方法时，key的hashCode用于确定将用于存储映射的存储区。
// 链表转换红黑树的阀值。当某个bin\buckets的长度大于8的时候进行转换。
static final int TREEIFY_THRESHOLD = 8;
// 红黑树转换链表的阀值。当某个bin\buckets的长度小于8的时候进行转换。
static final int UNTREEIFY_THRESHOLD = 6;
// 桶中bin最小hash容量，如果大于这个值会进行resize扩容操作，此值至少是TREEIFY_THRESHOLD的4倍
static final int MIN_TREEIFY_CAPACITY = 64;

// 被transient修饰的变量不回被序列化。
// HashMap内部类实现了Map的内部类Entry,用于存储K,V，第一次使用的时候被创建，根据需要可以进行resize。分配长度为2的冥次方
transient Node<K,V>[] table;
// 当被调用entrySet时被赋值。通过keySet()方法可以得到map key的集合，通过values方法可以得到map value的集合
transient Set<Map.Entry<K,V>> entrySet;

// size表示HashMap中存放KV的数量（为链表和树中的KV的总和）。
transient int size;

// 操作次数，通常用过fail-fast。每次扩容和更改map结构的计数器
transient int modCount;

// threshold=capacity*loadFactor threshold表示当HashMap的size大于threshold时会执行resize操作。 
int threshold;

// Load Factor用于确定何时重新散列HashMap并增加存储桶大小。存储桶或容量的默认值为16，负载系数为0.75。通过乘以容量和负载因子来计算重新散列的阈值
final float loadFactor;

Node

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

static class Node<K,V> implements Map.Entry<K,V> {
        final int hash; // node哈希值
        final K key;    
        V value;
        Node<K,V> next; // 下一个node的地址

        Node(int hash, K key, V value, Node<K,V> next) {
            this.hash = hash;
            this.key = key;
            this.value = value;
            this.next = next;
        }

        public final K getKey()        { return key; }
        public final V getValue()      { return value; }
        // 这里重写方法，所以map.toString()不是内存地址。
        public final String toString() { return key + "=" + value; }
  
			  // 这里重写了hashCode()方法
        public final int hashCode() {
            return Objects.hashCode(key) ^ Objects.hashCode(value);
        }
				
        public final V setValue(V newValue) {
            V oldValue = value;
            value = newValue;
            return oldValue;
        }
  
				// 这里重写了equals()方法
        public final boolean equals(Object o) {
            if (o == this)
                return true;
            //Map.Entry 相等的条件：键相等、值相等、个数相等、顺序相等
            if (o instanceof Map.Entry) {
                Map.Entry<?,?> e = (Map.Entry<?,?>)o;
                if (Objects.equals(key, e.getKey()) &&
                    Objects.equals(value, e.getValue()))
                    return true;
            }
            return false;
        }
    }

本章是整理知识内容，为强化知识长期更新。

Redis 简介

Redis 是完全开源免费的，遵守 BSD 协议，英文全称是Remote Dictionary Server（远程字典服务），是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

• Redis 与 其他 key - value 缓存产品有以下三个特点：
  • Redis 支持数据持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
  • Redis 不仅仅支持简单的 key - value 类型的数据，同时还提供 list，set，zset，hash 等数据结构的存储
  • Redis 支持数据的备份，即 master - slave 模式的数据备份。
• Redis是内存数据库，所有操作都在内存上完成，内存的访问速度本身就很快，读的速度是 110000 次 /s, 写的速度是 81000 次 /s。另一方面是因为它的数据结构。键值对是按一定的数据结构来组织的，操作键值对最终就是对数据结构进行增删改查操作，所以高效的数据结构是 Redis 快速处理数据的基础。
• Redis使用基于哈西槽(slot)的数据划分方式。

Redis数据类型与数据结构

数据结构时间复杂度

Redis单线程

• 我们通常说，Redis 是单线程，主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的，这也是 Redis 对外提供键值存储服务的主要流程。但 Redis 的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。Redis 的单线程设计机制以及多路复用机制
• Linux 中的 IO 多路复用机制
  • Linux 中的 IO 多路复用机制是指一个线程处理多个 IO 流，就是我们经常听到的 select/epoll 机制。简单来说，在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

Redis单线程处理IO请求性能瓶颈

• 任意一个请求在server中一旦发生耗时，都会影响整个server的性能，也就是说后面的请求都要等前面这个耗时请求处理完成，自己才能被处理到。耗时的操作包括以下几种：
  • 操作bigkey：写入一个bigkey在分配内存时需要消耗更多的时间，同样，删除bigkey释放内存同样会产生耗时；
  • 使用复杂度过高的命令：例如SORT/SUNION/ZUNIONSTORE，或者O(N)命令，但是N很大，例如lrange key 0 -1一次查询全量数据；
  • 大量key集中过期：Redis的过期机制也是在主线程中执行的，大量key集中过期会导致处理一个请求时，耗时都在删除过期key，耗时变长；
  • 淘汰策略：淘汰策略也是在主线程执行的，当内存超过Redis内存上限后，每次写入都需要淘汰一些key，也会造成耗时变长；
  • AOF刷盘开启always机制：每次写入都需要把这个操作刷到磁盘，写磁盘的速度远比写内存慢，会拖慢Redis的性能；
  • 主从全量同步生成RDB：虽然采用fork子进程生成数据快照，但fork这一瞬间也是会阻塞整个线程的，实例越大，阻塞时间越久；
• 并发量非常大时，单线程读写客户端IO数据存在性能瓶颈，虽然采用IO多路复用机制，但是读写客户端数据依旧是同步IO，只能单线程依次读取客户端的数据，无法利用到CPU多核。
• Redis在4.0推出了lazy-free机制，把bigkey释放内存的耗时操作放在了异步线程中执行，降低对主线程的影响。
• Redis在6.0推出了多线程，可以在高并发场景下利用CPU多核多线程读写客户端数据，进一步提升server性能，当然，只是针对客户端的读写是并行的，每个命令的真正操作依旧是单线程的。

Redis持久化机制

Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。

• Redis 4.0 之前数据持久化方式有两种：AOF 方式和 RDB 方式。

  • RDB（Redis DataBase，快照方式）是将某一个时刻的内存数据，以二进制的方式写入磁盘。RDB 默认的保存文件为 dump.rdb，优点是以二进制存储的，因此占用的空间更小、数据存储更紧凑，并且与 AOF 相比，RDB 具备更快的重启恢复能力。
  • AOF（Append Only File，文件追加方式）是指将所有的操作命令，以文本的形式追加到文件中。AOF 默认的保存文件为 appendonly.aof，它的优点是存储频率更高，因此丢失数据的风险就越低，并且 AOF 并不是以二进制存储的，所以它的存储信息更易懂。缺点是占用空间大，重启之后的数据恢复速度比较慢。

• 将RDB做镜像全量持久化，AOF做增量持久化。RDB会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。在redis实例重启时，会使用RDB持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启之前的状态。

  • 实现：单独创建fork()一个子进程，将当前父进程的数据库数据复制到子进程的内存中，然后由子进程内存释放。
  • RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。（ 快照可以是其所表示的数据的一个副本，也可以是数据的一个复制品。）

• AOF：Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

AOF日志

AOF持久化机制是以日志的形式记录Redis中的每一次的增删改操作，不会记录查询操作，以文本的形式记录，打开记录的日志文件就可以查看操作记录。

• AOF更好保证数据不会被丢失，最多只丢失一秒内的数据，通过foek一个子进程处理持久化操作，保证了主进程不会进程io操作，能高效的处理客户端的请求。

• AOF的日志文件的记录可读性非常的高，即使某一时刻有人执行flushall清空了所有数据，只需要拿到aof的日志文件，然后把最后一条的flushall给删除掉，就可以恢复数据。

AOF重写机制

在写入所有的操作到日志文件中时，就会出现日志文件很多重复的操作，甚至是无效的操作，导致日志文件越来越大。就浪费了资源空间，所以在Redis中出现了rewrite机制。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。

• 重写AOF的日志文件不是读取旧的日志文件瘦身，而是将内存中的数据用命令的方式重写一个AOF文件，重新保存替换原来旧的日志文件，因此内存中的数据才是最新的。

• 重写操作也会fork一个子进程来处理重写操作，重写以内存中的数据作为重写的源，避免了操作的冗余性，保证了数据的最新。

• 写后日志，“写后”的意思是 Redis 是先执行命令，把数据写入内存，然后才记录日志。

AOF 潜在的风险

• 如果刚执行完一个命令，还没有来得及记日志就宕机了，那么这个命令和相应的数据就有丢失的风险。如果此时 Redis 是用作缓存，还可以从后端数据库重新读入数据进行恢复，但是，如果 Redis 是直接用作数据库的话，此时，因为命令没有记入日志，所以就无法用日志进行恢复了。
• AOF 虽然避免了对当前命令的阻塞，但可能会给下一个操作带来阻塞风险。这是因为，AOF 日志也是在主线程中执行的，如果在把日志文件写入磁盘时，磁盘写压力大，就会导致写盘很慢，进而导致后续的操作也无法执行了。

AOF三种写回策略

• Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
  • 同步写回可以做到基本不丢数据，但是它在每一个写命令后都有一个慢速的落盘操作，不可避免地会影响主线程性能。
• Everysec，每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
  • 每秒写回采用一秒写回一次的频率，避免了“同步写回”的性能开销，虽然减少了对系统性能的影响，但是如果发生宕机，上一秒内未落盘的命令操作仍然会丢失。所以，这只能算是，在避免影响主线程性能和避免数据丢失两者间取了个折中。
• No，操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。
  • 操作系统控制的写回在写完缓冲区后，就可以继续执行后续的命令，但是落盘的时机已经不在 Redis 手中了，只要 AOF 记录没有写回磁盘，一旦宕机对应的数据就丢失了。

RDB快照

RDB持久化就是将当前进程的数据以生成快照的形式持久化到磁盘中。对于快照的理解，我们可以理解为将当前线程的数据以拍照的形式保存下来。

• 恢复数据速度快
• 写入持久化文件快
• RDB持久化后的文件是紧凑的二进制文件，适合于备份、全量复制、大规模数据恢复的场景，对数据完整性和一致性要求不高，RDB会丢失最后一次快照的数据。

RDB原理

• fork和cow。fork是指redis通过创建子进程来进行RDB操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

• Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就是说，把内存中的所有数据都记录到磁盘中。全量数据越多，RDB 文件就越大，往磁盘上写数据的时间开销就越大。

• 对于 Redis 而言，它的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的操作，所以，针对任何操作，我们都会提一个灵魂之问：“它会阻塞主线程吗?”RDB 文件的生成是否会阻塞主线程，这就关系到是否会降低 Redis 的性能。

• Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。

  • save：在主线程中执行，会导致阻塞；
  • bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。

Redis启动持久化文件加载机制

Redis是基于内存的非关系型K-V数据库，它是基于内存的，如果Redis服务器挂了，数据就会丢失。为了避免数据丢失了，Redis提供了持久化，即把数据保存到磁盘。

缓存带来的问题

缓存雪崩

• 我们可以简单的理解为：由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。
• 解决办法：
  • 大多数系统设计者考虑用加锁（ 最多的解决方案）或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就是将缓存失效时间分散开。
  • 服务层增加熔断、降级、限流等操作，防止系统被流量攻溃。
  • 增加redis的监控措施，并采用高可用架构处理。

缓存穿透

• 缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。
• 解决办法

1. 缓存空对象：代码维护较简单，但是效果不好。
2. 布隆过滤器：代码维护复杂，空间效率和查询时间都远远超过一般的算法，效果很好。有一定的误识别率，删除困难。
3. 请求参数检验：防止恶意请求进入业务系统，将部分恶意请求拦截掉。

• 布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
• 缓存空对象,一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。
• 布隆过滤器（推荐）
  • 就是引入了k(k>1)k(k>1)个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。Hash存在一个冲突（碰撞）的问题，用同一个Hash得到的两个URL的值有可能相同。为了减少冲突，我们可以多引入几个Hash，如果通过其中的一个Hash值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的Hash函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是Bloom-Filter的基本思想。Bloom-Filter一般用于在大数据量的集合中判定某元素是否存在。

布隆过滤器

布隆过滤器是一种基于概率的数据结构，主要用来判断某个元素是否在集合内，它具有运行速度快（时间效率），占用内存小的优点（空间效率），但是有一定的误识别率和删除困难的问题。它只能告诉你某个元素一定不在集合内或可能在集合内。

1. 一个非常大的二进制位数组 （数组里只有0和1）
2. 若干个哈希函数
3. 空间效率和查询效率高
4. 不存在漏报（False Negative）：某个元素在某个集合中，肯定能报出来。
5. 可能存在误报（False Positive）：某个元素不在某个集合中，可能也被爆出来。
6. 不提供删除方法，代码维护困难。
7. 位数组初始化都为0，它不存元素的具体值，当元素经过哈希函数哈希后的值（也就是数组下标）对应的数组位置值改为1。

布隆过滤器案例

当查询一件商品的缓存信息，布隆过滤器只能精确判断数据不存在情况，对于存在我们只能说是可能，因为存在Hash冲突情况，当然这个概率非常低。

1. 当查询一件商品的缓存信息
2. 然后，在布隆数组中查找访问对应的位值，0或1
3. 判断，三个值中，只要有一个不是1，那么我们认为数据是不存在的。

布隆过滤器删除问题

直接删除肯定不行，存在hash冲突，存在误删。

• 定时任务，定期创建一个新的布隆过滤器。

如何减少布隆过滤器的误判

• 增加二进制位数组的长度。这样经过hash后数据会更加的离散化，出现冲突的概率会大大降低。
• 增加Hash的次数，变相的增加数据特征。特征数据越多，冲突的概率越小。

缓存击穿

缓存击穿是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，瞬间对数据库的访问压力增大。

• 当用户出现大并发访问的时候，在查询缓存的时候和查询数据库的过程加锁，只能第一个进来的请求进行执行，当第一个请求把该数据放进缓存中，接下来的访问就会直接集中缓存，防止了缓存击穿。即根据key获取value值为空时，锁上，从数据库中load数据后再释放锁。若其它线程获取锁失败，则等待一段时间后重试。这里要注意，分布式环境中要使用分布式锁，单机的话用普通的锁（synchronized、Lock）就够了。
  • 使用互斥锁方案缓存失效时，不是立即去加载db数据，而是先使用某些带成功返回的原子操作命令，如(Redis的setnx）去操作，成功的时候，再去加载db数据库数据和设置缓存。否则就去重试获取缓存。
  • 持续不过期,通过定时任务的方式同步数据到缓存中。防止热key数据过期。

缓存预热

• 缓存预热这个应该是一个比较常见的概念，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

缓存更新

• 除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：
  • 定时去清理过期的缓存；
  • 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
• 两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

缓存降级

• 当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
  • 以参考日志级别设置预案：
    • 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
    • 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
    • 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
    • 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。
• 服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

数据一致性

缓存一致性问题作为日常开发长期存在的问题。

缓存常见的操作

• 写入：缓存和数据库是两个不同的组件，只要涉及双写，就存在只有一个写成功的可能性，造成数据不一致。

• 更新：更新的情况类似，需要更新两个不同的组件。

• 读取：读取要保证从缓存中读到的信息是最新的，是和数据库中的是一致的。

• 删除：当删除数据库记录的时候，如何把缓存中的数据也删掉？

同步直写

• 写数据库的时候也写入缓存，通过代码检查机制使数据库和缓存数据统一。通常会采用事务、重试机制来保证数据。

延时双删

• 先更新再删除，但是执行删除动作，在不久之后再执行一次，比如 1-5 秒之后。

集中更新

• 弱化数据库，将数据优先存放到redis总，在通过定时器或扫描逻辑代码将数据同步到mysql中。

触发式加载

使用懒加载的方式，可以让缓存的同步变得非常简单

• 当读取缓存的时候，如果缓存里没有相关数据，则执行相关的业务逻辑，构造缓存数据存入到缓存系统；

• 当与缓存项相关的资源有变动，则先删除相应的缓存项，然后再对资源进行更新，这个时候，即使是资源更新失败，也是没有问题的。

缓存热key

什么是热Key呢？在Redis中，我们把访问频率高的key，称为热点key。

• 如果某一热点key的请求到服务器主机时，由于请求量特别大，可能会导致主机资源不足，甚至宕机，从而影响正常的服务。
  • Redis集群扩容：增加分片副本，均衡读流量；
  • 使用二级缓存，即JVM本地缓存,减少Redis的读请求。

Redis 的线程模型

• redis 内部使⽤⽂件事件处理器file event handler，这个⽂件事件处理器是单线程的，所以redis 才叫做单线程的模型。它采⽤ IO 多路复⽤机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进⾏处理。

单线程的Redis为什么这么快

• 存内存操作。
• 单线程操作，避免平凡的上下文切换。
• 采用了非阻塞I/O多路复用操作。（这里的I/O是指网络I/O）

Redis的过期策略以及内存淘汰机制

• redis采用的是定期删除+惰性删除策略。

  • 定期删除，redis默认每个100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

• 定时删除

  • 每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即对key进行清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。

• 内存淘汰策略

当Redis内存快耗尽时，Redis会启动内存淘汰机制，将部分key清掉以腾出内存。

• 主要有5种处理机制
  • LRU 最近最少使用
  • LFU 最近使用频率低
  • Random 随机淘汰
  • TTL 过期时间
  • No-Enviction 驱逐（什么都不做直接返回错误）
• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。
• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
• volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key。
• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰。
• allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰。
• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰。
• no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错。
• 如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

Redis 的过期策略和内存淘汰机制有什么区别？

• 新增 Redis 缓存时可以设置缓存的过期时间，该时间保证了数据在规定的时间内失效。通过这种方式可以完成某些场景的业务开发。对对于已经过期的数据，Redis 将使用两种策略来删除这些过期键，它们分别是惰性删除和定期删除。

• 惰性删除是指 Redis 服务器不主动删除过期的键值，而是当访问键值时，再检查当前的键值是否过期，如果过期则执行删除并返回 null 给客户端；如果没过期则正常返回值信息给客户端。

• 定期删除是指 Redis 服务器每隔一段时间会检查一下数据库，看看是否有过期键可以被清除。默认情况下 Redis 定期检查的频率是每秒扫描 10 次，用于定期清除过期键。当然此值还可以通过配置文件进行设置，在 redis.conf 中修改配置“hz”即可，默认的值为“hz 10”。Redis 服务器为了保证过期删除策略不会导致线程卡死，会给过期扫描增加了最大执行时间为 25ms。

• 当 Redis 的内存超过最大允许的内存之后，Redis 会触发内存淘汰策略，这和过期策略是完全不同的两个概念，经常有人把二者搞混，这两者一个是在正常情况下清除过期键，一个是在非正常情况下为了保证 Redis 顺利运行的保护策略。

本章是整理知识内容，为强化知识长期更新。

整体架构

基础层

处理层

接口层

Mybatis执行流程

• 获取sqlSessionFactory对象:解析文件的每一个信息保存在Configuration中，返回包含Configuration的DefaultSqlSession；注意：MappedStatement：代表一个增删改查的详细信息。
• 获取sqlSession对象,返回一个DefaultSQlSession对象，包含Executor和Configuration;这一步会创建Executor对象；
• 获取接口的代理对象（MapperProxy）,getMapper，使用MapperProxyFactory创建一个MapperProxy的代理对象。

Mybatis拦截器

代理对象里面包含了，DefaultSqlSession（Executor）

• 执行增删改查方法。
  • 调用DefaultSqlSession的增删改查（Executor）
  • 创建一个StatementHandler对象、且同时创建出ParameterHandler和ResultSetHandler。
  • 调用StatementHandler预编译参数以及设置参数值;使用ParameterHandler来给sql设置参数
  • 调用StatementHandler的增删改查方法；
  • ResultSetHandler封装结果
• MyBatis 拦截签名 拦截器签名是一个名为 @Intercepts 的注解，该注解中可以通过 @Signature 配置多个签名。@Signature 注解中则包含三个属性
  • type: 拦截器需要拦截的接口，有 4 个可选项，分别是：Executor、ParameterHandler、ResultSetHandler 以及 StatementHandler。
  • method: 拦截器所拦截接口中的方法名，也就是前面四个接口中的方法名，接口和方法要对应上。
  • args: 拦截器所拦截方法的参数类型，通过方法名和参数类型可以锁定唯一一个方法。
• 被拦截的对象
  • org.apache.ibatis.executor.Executor
  • org.apache.ibatis.executor.statement.StatementHandler
  • org.apache.ibatis.executor.statement.ParameterHandler
  • org.apache.ibatis.executor.resultset.ResultSetHandler
• Executor
  • update：该方法会在所有的 INSERT、 UPDATE、 DELETE 执行时被调用，如果想要拦截这些操作，可以通过该方法实现。
  • query：该方法会在 SELECT 查询方法执行时被调用，方法参数携带了很多有用的信息，如果需要获取，可以通过该方法实现。
  • queryCursor：当 SELECT 的返回类型是 Cursor 时，该方法会被调用。
  • flushStatements：当 SqlSession 方法调用 flushStatements 方法或执行的接口方法中带有 @Flush 注解时该方法会被触发。
  • commit：当 SqlSession 方法调用 commit 方法时该方法会被触发。
  • rollback：当 SqlSession 方法调用 rollback 方法时该方法会被触发。
  • getTransaction：当 SqlSession 方法获取数据库连接时该方法会被触发。
  • close：该方法在懒加载获取新的 Executor 后会被触发。
  • isClosed：该方法在懒加载执行查询前会被触发。
• StatementHandler
  • prepare：该方法在数据库执行前被触发。
  • parameterize：该方法在 prepare 方法之后执行，用来处理参数信息。
  • batch：如果 MyBatis 的全剧配置中配置了 defaultExecutorType=”BATCH”，执行数据操作时该方法会被调用。
  • update：更新操作时该方法会被触发。
  • query：该方法在 SELECT 方法执行时会被触发。
  • queryCursor：该方法在 SELECT 方法执行时，并且返回值为 Cursor 时会被触发。
• ParameterHandler
  • getParameterObject：在执行存储过程处理出参的时候该方法会被触发。
  • setParameters：设置 SQL 参数时该方法会被触发。
• ResultSetHandler
  • handleResultSets：该方法会在所有的查询方法中被触发（除去返回值类型为 Cursor 的查询方法），一般来说，如果我们想对查询结果进行二次处理，可以通过拦截该方法实现。
  • handleCursorResultSets：当查询方法的返回值类型为 Cursor 时，该方法会被触发。
  • handleOutputParameters：使用存储过程处理出参的时候该方法会被调用。

MyBatis插件

MyBatis 将插件单独分离出一个模块，位于 org.apache.ibatis.plugin 包中，在该模块中主要使用了两种设计模式：代理模式和责任链模式。

• 插件接口

  • org.apache.ibatis.plugin.Interceptor

  • intercept：它将直接覆盖你所拦截的对象，有个参数Invocation对象，通过该对象，可以反射调度原来对象的方法；

  • plugin：target是被拦截的对象，它的作用是给被拦截对象生成一个代理对象；

  • setProperties：允许在plugin元素中配置所需参数，该方法在插件初始化的时候会被调用一次；

• MyBatis允许我们自定义 Interceptor 拦截 SQL 语句执行过程中的某些关键逻辑，允许拦截的方法有：Executor 类中的 update()、query()、flushStatements()、commit()、rollback()、getTransaction()、close()、isClosed()方法，ParameterHandler 中的 setParameters()、getParameterObject() 方法，ResultSetHandler中的 handleOutputParameters()、handleResultSets()方法，以及StatementHandler 中的parameterize()、prepare()、batch()、update()、query()方法。

MyBatis中的设计模式

• 工厂模式
  • 工厂模式在 MyBatis 中的典型代表是 SqlSessionFactory。
  • SqlSession 是 MyBatis 中的重要 Java 接口，可以通过该接口来执行 SQL 命令、获取映射器示例和管理事务，而 SqlSessionFactory 正是用来产生 SqlSession 对象的，所以它在 MyBatis 中是比较核心的接口之一。
  • 工厂模式应用解析：SqlSessionFactory 是一个接口类，它的子类 DefaultSqlSessionFactory 有一个 openSession(ExecutorType execType) 的方法，其中使用了工厂模式。
• 建造者模式
  • MyBatis 中的典型代表是 SqlSessionFactoryBuilder。
  • 普通的对象都是通过 new 关键字直接创建的，但是如果创建对象需要的构造参数很多，且不能保证每个参数都是正确的或者不能一次性得到构建所需的所有参数，那么就需要将构建逻辑从对象本身抽离出来，让对象只关注功能，把构建交给构建类，这样可以简化对象的构建，也可以达到分步构建对象的目的，而 SqlSessionFactoryBuilder 的构建过程正是如此。
  • 在 SqlSessionFactoryBuilder 中构建 SqlSessionFactory 对象的过程是这样的，首先需要通过 XMLConfigBuilder 对象读取并解析 XML 的配置文件，然后再将读取到的配置信息存入到 Configuration 类中，然后再通过 build 方法生成我们需要的 DefaultSqlSessionFactory 对象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {

    try {
        XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
        return build(parser.parse());
    } catch (Exception e) {
        throw ExceptionFactory.wrapException("Error building SqlSession.", e);
    } finally {
        ErrorContext.instance().reset();
        try {
        inputStream.close();
        } catch (IOException e) {
        // Intentionally ignore. Prefer previous error.
        }
    }
}

public SqlSessionFactory build(Configuration config) {
    return new DefaultSqlSessionFactory(config);
}

• 单例模式
  • 单例模式在 MyBatis 中的典型代表是 ErrorContext。
  • 使用 private 修饰的 ThreadLocal 来保证每个线程拥有一个 ErrorContext 对象，在调用 instance() 方法时再从 ThreadLocal 中获取此单例对象。

1
2
3
4
5
6
7
8
9
10

public class ErrorContext {

  private static final String LINE_SEPARATOR = System.lineSeparator();
  // 每个线程存储的容器
  private static final ThreadLocal<ErrorContext> LOCAL = ThreadLocal.withInitial(ErrorContext::new);

  public static ErrorContext instance() {
    return LOCAL.get();
  }
}

• 适配器模式

  • MyBatis 中的典型代表是 Log。
    • SLF4J
    • Apache Commons Logging
    • Log4j 2
    • Log4j
    • JDK logging

• 代理模式

  • 代理模式在 MyBatis 中的典型代表是 MapperProxyFactory。

• 模版方法模式

  • 模板方法在 MyBatis 中的典型代表是 BaseExecutor。

• 装饰器模式

  • 装饰器模式在 MyBatis 中的典型代表是 Cache。

Mybatis一些疑问

#{} 于 ${}

使用#{}可以有效的防止SQL注入，提高系统安全性。

• #{}是预编译,${}是字符串替换。
  • Mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值；
  • Mybatis在处理${}时，就是把${}替换成变量的值。

MyBatis Dao 接口的工作原理

• Dao 接口的全限定名，就是映射文件中的 namespace 的值，接口的方法名，就是映射文件中 Mapper 的 Statement 的 id 值，接口方法内的参数，就是传递给 SQL 的参数。Mapper 接口是没有实现类的，当调用接口方法时，接口全限定名 + 方法名拼接字符串作为 key 值，可唯一定位一个 MapperStatement。在 MyBatis 中，每一个 select、insert、update、delete 标签，都会被解析为一个 MapperStatement 对象。

Dao 接口里的方法可以重载吗

• Mapper 接口的工作原理是 JDK 动态代理，MyBatis 运行时会使用 JDK 动态代理为 Mapper 接口生成代理对象 proxy，代理对象会拦截接口方法，转而执行 MapperStatement 所代表的 SQL，然后将 SQL 执行结果返回。所以是不能重载的

本章是整理知识内容，为强化知识长期更新。

Java集合

​ 集合是Java提供的工具包、包含常用的数据结构：集合、链表、队列、栈、数组、映射等。Collection的包是java.util.*。

Collection

Map

实际上还有Cloneable、Serializable接口是都集合类需要实现的，通用所以不不画上去了。

Java集合主要划分4个部分：

• List(列队)
• Set(集合)
• Map(映射)
• 工具类(Iterator迭代器、Enumeration枚举类、Arrays、Collections)

划重点

• Conllection
  • List
    • ArrayList
    • Vector
      • Stack
    • LinkedList
  • Set
    • HashSet
    • TreeSet
    • LinkedHashSet
  • Queue
• Map
  • HashMap
  • HashTable
  • TreeMap
• 工具
  • Arrays
  • Collections
  • Enumeration

Java类库中具体集合

本章是整理知识内容，为强化知识长期更新。

Git速度查询表

下面是常用 的Git 命令清单。几个专用名词的译名如下：

• Workspace：工作区
• Index / Stage：暂存区
• Repository：仓库区（或本地仓库）
• Remote：远程仓库

最小配置

为什么要最小配置,每次提交代码需要告诉git。所以需要简单设置下user信息。

1
2

git config --global user.name 'your name'
git config --global user.email 'your email'

这里需要注意config的三个作用域

1
2
3

git config --local  #某个git本地仓库有效
git config --global #当前用户所有仓库有效，就是你系统的登陆用户。
git config --system #对系统所有的仓库都有效果。

我们一般只会使用local 和 global这两个配置。当我们配置好user.name user.email之后，我们可以检查下配置信息。

1
2
3

git config --list --local # 注意，必须在某个仓库里面才能看到。
git config --list --global
git config --list --system

创建一个本地仓库

一般来说git仓库有两种情况，一种是没有仓库，另外一种就是已经有仓库了。这里对第一种情况演示，因为工作中习惯在web上创建仓库。这里还是了解下。

1

git init git_learning

创建一个README文件。

1

touch README.md

这里需要说明下，本地仓库创建完成后需要与远程仓库进行管理。

1

git remote add origin github.com:yourname/git_learning.git # 这里的yourname 是你的git账号

建议手动去github上面创建一个叫git_learning的仓库。上面的命令就是做下关联。

1
2
3

git add . # 将当前文件添加至暂存区
git commit -m "upload file" # 将暂存区的文件提交到本地仓库
git push origin mastet # 将本地仓库的改动信息推送到远程仓库中

可控一个远程仓库

1
2

# 克隆一个仓库
git clone www.**/**.git

文件追踪

有些时候不想提交部分文件，但是git add .的时候添加进去了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

## 添加文件到暂存区
git add [file] [file] 

## 添加文件夹暂存区
git add [dir]

## 添加当前目录所有文件暂存区
git add .

## 如果是对所有文件都取消跟踪的话，就是
git rm -r --cached . 　　       ## 不删除本地文件
git rm -r --f . 　　            ## 删除本地文件

##对某个文件取消跟踪
git rm --cached readme1.txt    ## 删除readme1.txt的跟踪，并保留在本地。
git rm --f readme1.txt         ## 删除readme1.txt的跟踪，并且删除本地文件s

提交仓库

如果发现message写错了，可以修改下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 修改最新一次commit提交message。
git commit --amend  

# 提交暂存区的指定文件到仓库区
git commit [file1] [file2] ... -m [message]

# 将本地暂存区的文件推送到本地仓库。 当修改已经通过`git add <change file>`将其添加到`stage`，可以通过`git commit -m "<message>"`为这所有已经进入`stage`的改变添加一个`commit`信息。
git commit -m

#可以直接使用`git commit -am "<message>"`，将所有修改，但未进`stage`的改动加入`stage`，并记录`commit`信息。(某种程度上相当于`git add`和`git commit -m`的组合技，前提是被改动文件已经是`tracked`)
git commit -am

#这个命令经常会出现在本地仓库与远程仓库发生冲突的时候，需要强制推送更新。
git push -f origin master

# 推送删除远程分支操作
git push origin : xxxx

# 推送删除远程分支操作
git push origin --delete xxxx

• 如果想修改以往的commit的message。注意是不连续的commit。
  • 首先查看log 里面的信息,然后获取commitid进行合并

本章是整理知识内容，为强化知识长期更新。

Vector

概述

• Vector是Java Collection Franmework成员。
• 列队允许添加重复元素
• 列队允许null的存在
• 列队从0开始，也就是列队头部的下标是0。
• 列队支持泛型，这样可以避免ClassCastException异常。

与ArrayList的区别

本章是整理知识内容，为强化知识长期更新。

Stack

• 栈是元素的集合，其包含了两个基本操作：push 操作可以用于将元素压入栈，pop 操作可以将栈顶元素移除。
• 遵循后入先出（LIFO）原则。
• 时间复杂度:
• 索引: O(n)
• 搜索: O(n)
• 插入: O(1)
• 移除: O(1)

Stack

Collection成员之一，继承了Vector，通过重写Vector来实现LIFO（Last-in-First-out 后进先出）特性。

概述

• Java Stack是LIFO对象。它扩展了Vector类。

源码分析Stack

本章是整理知识内容，为强化知识长期更新。

Linked List

• 链表即是由节点（Node）组成的线性集合，每个节点可以利用指针指向其他节点。它是一种包含了多个节点的、能够用于表示序列的数据结构。
• 单向链表: 链表中的节点仅指向下一个节点，并且最后一个节点指向空。
• 双向链表: 其中每个节点具有两个指针 p、n，使得 p 指向先前节点并且 n 指向下一个节点；最后一个节点的 n 指针指向 null。
• 循环链表：每个节点指向下一个节点并且最后一个节点指向第一个节点的链表。
• 时间复杂度:
  • 索引: O(n)
  • 搜索: O(n)
  • 插入: O(1)
  • 移除: O(1)

LinkedList 是是一个有序的集合，是Collection的实现类之一。

概述

• 双链表 LinkedList 是 Java Collecion Framework成员之一。
• 双链表 是List和Deque的接口的实现。
• 在内部，它是使用双链表数据结构实现的。
• 它支持重复的元素。它没有实现RandomAccess接口。所以我们只能按顺序访问元素。它不支持随机访问元素。
• 相对与ArrayList它 删除 和添加 速度会快很多。但是遍历就要慢一些。
• 它以插入顺序存储或维护它的元素。

链表

本章属于持续学习、长期更修。

HashSet

特性

• HashSet不允许重复数据。
• HashSet不允许null，因为null也是可以重复的。
• HashSet不保证数据的插入顺序。
• HashSet不是线程安全的，如果想使用线程的安全的HashSet可以通过Collections.synchronizedSet 来获取线程安全的HashSet。也可以使用CopyOnWriteArraySet。但是性能会有很大的损失。
• HashSet迭代器方法是快速失败的。因此，在创建迭代器之后对集合进行任何结构修改都会抛出ConcurrentModificationException。
• HashSet支持泛型，这是在运行时避免ClassCastException的推荐方法。
• HashSet使用HashMap存储元素，因此对象应该提供hashCode（）和equals（）方法的良好实现，以避免不必要的结果。

源码分析