所有题目均为自己整理,因此并非标准答案,仅希望能对有面试或者学习的小伙伴有所帮助。但更希望是自己能去整理、归纳、总结,这样会印象更深刻。
答案搜集并非都完整,后续有时间也会补充完善。
方法返回类型 | 方法 | 描述 |
---|---|---|
protected Object | clone() | 创建并返回此对象的副本 |
boolean | equals(Object obj) | 判断其他对像是否与其相等 |
protected void | finalize() | 当GC确定不再有对该对象的引用时,GC在对象上调用该方法 |
类> | getClass() | 返回此Object的运行时类 |
int | hashCode() | 返回对象的哈希码值 |
void | notify() | 唤醒正在等待对象监视器的单个线程 |
void | notifyAll() | 唤醒正在等待对象监视器的所有线程 |
String | toString() | 返回对象的字符串表示形式 |
void | wait() | 导致当前线程等待,直到另一个线程调用该对象的notify()方法或者nitifyAll()方法 |
void | wait(long timeout) | 导致当前线程等待,直到另一个线程调用notify()方法或者notifyAll()方法,或者指定的时间已过 |
void | wait(long timeout, int nanos) | 导致当前线程等待,直到另一个线程调用该对象的notify()方法或者notifyAll()方法,或者某些其他线程中断当前线程,或者一定量的实时时间 |
String对象的方法有哪些?分别有什么用?该什么场景用?
扩展: Java内存分配之堆、栈和常量池
栈
在函数中定义的一些基本类型的变量数据和对象的引用变量都在函数的栈内存中分配。当在一段代码块定义一个变量时,Java就在栈中为这个变量分配内存空间,当该变量退出该作用域后,Java会自动释放掉为该变量所分配的内存空间,该内存空间可以立即被另作他用。
堆
堆内存用来存放由new创建的对象和数组。在堆中分配的内存,由Java虚拟机的自动垃圾回收器来管理。
在堆中产生了一个数组或对象后,还可以 在栈中定义一个特殊的变量,让栈中这个变量的取值等于数组或对象在堆内存中的首地址,栈中的这个变量就成了数组或对象的引用变量。引用变量就相当于是为数组或对象起的一个名称,以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。引用变量就相当于是为数组或者对象起的一个名称。
引用变量是普通的变量,定义时在栈中分配,引用变量在程序运行到其作用域之外后被释放。而数组和对象本身在堆中分配,即使程序运行到使用 new 产生数组或者对象的语句所在的代码块之外,数组和对象本身占据的内存不会被释放,数组和对象在没有引用变量指向它的时候,才变为垃圾,不能在被使用,但仍 然占据内存空间不放,在随后的一个不确定的时间被垃圾回收器收走(释放掉)。这也是 Java 比较占内存的原因。
实际上,栈中的变量指向堆内存中的变量,这就是Java中的指针!
常量池
常量池指的是在编译期被确定,并被保存在已编译的.class文件中的一些数据
除了包含代码中所定义的各种基本类型(如int、long等等)和对象型(如String及数组)的常量值(final修饰的)还包含一些以文本形式出现的符号引用,比如:
1. 类和接口的全限定名;
2. 字段的名称和描述符;
3. 方法和名称和描述符。
虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集和,包括直接常量(string,integer和 floating point常量)和对其他类型,字段和方法的符号引用。
对于String常量,它的值是在常量池中的。而JVM中的常量池在内存当中是以表的形式存在的, 对于String类型,有一张固定长度的CONSTANT_String_info表用来存储文字字符串值,注意:该表只存储文字字符串值,不存储符号引 用。说到这里,对常量池中的字符串值的存储位置应该有一个比较明了的理解了。
在程序执行的时候,常量池会储存在Method Area,而不是堆中
拓展
1. 思考 String s = “abc”;的过程和数据存储分布?
步骤:
1)栈中开辟一块空间存放引用s;
2)String池中开辟一块空间,存放String常量”abc”;
3)引用s指向池中String常量”abc”。
2. new customObject(),该对象中包含静态、基本类型、对象类型(String、Object)的属性,那他们分别被分配在什么位置?
参考文章——Java虚拟机(2)-Java常量,变量,对象(字面量)在内存中的存储位置
三大特性 : 封装、继承、多态
封装
把对象的属性和行为(方法)结合成一个独立的整体,并尽可能隐藏对象的内部实现细节。
1. 把对象的属性私有化,同时提供一些可以被外界访问属性的方法(如getter,setter)
2. 容易修改类的内部实现,而无需修改使用了该类的客户代码。
3. 可以对成员变量进行更精确的控制。
继承
子类继承父类的属性和行为,并能根据自己的需求扩展出新的属性和行为,提高了代码的可复用性
1. 使用已存在的类的定义作为基础,建立新类的技术,新类的定义可以增加新的数据或新的功能,也可以用父类的功能,但不能选择性的继承父类
2. 子类拥有父类非private的属性和方法
3. 子类可以拥有自己的属性和方法,即子类可以对父类进行扩展
4. 子类可以用自己的方式实现父类的方法
构造器: 除了private之外,还有一些是子类不能继承的。比如:构造器只能被调用,而不能被继承。调用父类只要使用super()即可。子类会默认调用父类的默认构造器,如果没有默认构造器,就必须显示指出构造器。
protected: 对于protected而言,他指明就类用户而言,他是private,但是对于任何继承与此类的子类而言或者其他任何位于同一个包的类而言,他却是可以访问的。
向上转型: 将子类转换成父类,在继承关系上面是向上移动的,所以一般称之为向上转型。由于向上转型是从一个专用类型向通用类型转换,所以他总是安全的,唯一发生变化的可能就是属性和方法的丢失。这就是为什么编译器在“未明确表示转型”或“未指定特殊类型”的情况下,仍然允许向上转型的原因。
多态
封装和继承都是为Java语言的多态提供了支持
多态存在的三个必要条件:
要有继承
要有重写
父类引用指向子类对象
Map可以使用多种实现方式,HashMap的实现采用的是hash表;而TreeMap采用的是红黑树。
HashMap
实现了Map接口,实现了将唯一键映射到特定值上。允许一个NULL键和多个NULL值。非线程安全。
HashTable
类似于HashMap,但是不允许NULL键和NULL值,比HashMap慢,因为它是同步的。HashTable是一个线程安全的类,它使用synchronized来锁住整张Hash表来实现线程安全,即每次锁住整张表让线程独占。
ConcurrentHashMap
ConcurrentHashMap允许多个修改操作并发进行,其关键在于使用了锁分离技术。它使用了多个锁来控制对hash表的不同部分进行的修改。ConcurrentHashMap内部使用段(Segment)来表示这些不同的部分,每个段其实就是一个小的Hashtable,它们有自己的锁。只要多个修改操作发生在不同的段上,它们就可以并发进行。
JDK1.7的实现
在JDK1.7版本中,ConcurrentHashMap的数据结构是由一个Segment数组和多个HashEntry组成,如下图所示:
Segment数组的意义就是将一个大的table分割成多个小的table来进行加锁,也就是上面的提到的锁分离技术,而每一个Segment元素存储的是HashEntry数组+链表,这个和HashMap的数据存储结构一样
JDK1.8的实现
JDK1.8的实现已经摒弃了Segment的概念,而是直接用Node数组+链表+红黑树的数据结构来实现,并发控制使用Synchronized和CAS来操作,整个看起来就像是优化过且线程安全的HashMap,虽然在JDK1.8中还能看到Segment的数据结构,但是已经简化了属性,只是为了兼容旧版本。
参考文章——ConcurrentHashMap 1.8为什么要使用CAS+Synchronized取代Segment+ReentrantLock
HashMap和HashTable的区别
区别 | HashMap | HashTable |
---|---|---|
线程安全性 | 线程不安全 | 线程安全 |
Null值 | 允许有null的键和值 | 不允许有null的键和值 |
效率 | 效率高一点 | 效率稍低 |
同步性 | 方法不是Synchronize的,要提供外同步 | 方法是Synchronize的 |
包含方法 | 有containsValue和containsKey方法 | 有contains方法方法 |
继承或实现 | HashMap 是Java1.2 引进的Map interface 的一个实现 | Hashtable 继承于Dictionary 类 |
出现时间 | HashMap是Hashtable的轻量级实现 | Hashtable 比HashMap 要旧 |
参考文章
扩展
1. HashMap中链表节点插入位置?
for (int binCount = 0; ; ++binCount) {
if ((e = p.next) == null) {
p.next = newNode(hash, key, value, null); //追加到单链表末尾
if (binCount >= TREEIFY_THRESHOLD - 1) // //超过树化阈值则进行树化操作
treeifyBin(tab, hash);
break;
}
if (e.hash == hash &&
((k = e.key) == key || (key != null && key.equals(k))))
break;
p = e;
}
2. null key存储的位置?以及取模为0的元素存储位置?
//将key的哈希值,进行高16位和低16位异或操作,增加低16位的随机性,降低哈希冲突的可能性
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
如果key为null,hash结果为0
index=(n-1)&hash的方式,找到索引位置为0
参考文章——彻底理解HashMap的元素插入原理
1.开放定址法:
2.链地址法
3.再哈希
4.建立公共溢出区
参考文章
效率低下的HashTable容器
HashTable容器使用synchronized来保证线程安全,但在线程竞争激烈的情况 下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法时,其他线程访问HashTable的同步方法时,可能会进入阻塞 或轮询状态。如线程1使用put进行添加元素,线程2不但不能使用put方法添加元素,并且也不能使用get方法来获取元素,所以竞争越激烈效率越低。
锁分段技术
HashTable容器在竞争激烈的并发环境下表现出效率低下的原因是所有访问HashTable的线程都必须竞争同一把锁,那假如容器里有多把 锁,每一把锁用于锁容器其中一部分数据,那么当多线程访问容器里不同数据段的数据时,线程间就不会存在锁竞争,从而可以有效的提高并发访问效率,这就是 ConcurrentHashMap所使用的锁分段技术,首先将数据分成一段一段的存储,然后给每一段数据配一把锁,当一个线程占用锁访问其中一个段数据 的时候,其他段的数据也能被其他线程访问。
java5中新增了ConcurrentMap接口和它的一个实现类 ConcurrentHashMap。ConcurrentHashMap提供了和Hashtable以及SynchronizedMap中所不同的锁机 制。Hashtable中采用的锁机制是一次锁住整个hash表,从而同一时刻只能由一个线程对其进行操作;而ConcurrentHashMap中则是 一次锁住一个桶。ConcurrentHashMap默认将hash表分为16个桶,诸如get,put,remove等常用操作只锁当前需要用到的桶。 这样,原来只能一个线程进入,现在却能同时有16个写线程执行,并发性能的提升是显而易见的。
上面说到的16个线程指的是写线程,而读操作大部分时候都不需要用到锁。只有在size等操作时才需要锁住整个hash表。
在迭代方面,ConcurrentHashMap使用了一种不同的迭代方式。在这种迭代方式中,当iterator被创建后集合再发生改变就不再是抛出ConcurrentModificationException,取而代之的是在改变时new新的数据从而不影响原有的数据,iterator完成后再将头指针替换为新的数据,这样iterator线程可以使用原来老的数据,而写线程也可以并发的完成改变。
一.synchronized关键字:
import static java.lang.System.out;
public class Counting {
public static void main(String[] args)
throws InterruptedException {
class Count{
private int count=0;
public synchronized void increment(){count++;}
public int getCount(){return count;}
}
final Count counter=new Count();
class CountingThread extends Thread {
public void run(){
for (int i=0; i<1000;i++ ) {
counter.increment();
}
}
}
CountingThread t1=new CountingThread();
CountingThread t2=new CountingThread();
t1.start();
t2.start();
t1.join();
t2.join();
out.println(counter.getCount());
}
}
二.使用锁:
import static java.lang.System.out;
import java.util.concurrent.locks.ReentrantLock;
public class thread02 {
public static int count=0;
public static void main(String[] args) throws InterruptedException{
ReentrantLock lock=new ReentrantLock();
class My_thread01 extends Thread{
public void run(){
lock.lock();
try{
for(int i=0; i<10000;i++) {
count++;
}
}
finally{
lock.unlock();
}
}
}
class My_thread02 extends Thread{
public void run(){
lock.lock();
try{
for(int i=0; i<10000;i++) {
count++;
}
}
finally{
lock.unlock();
}
}
}
My_thread01 t1=new My_thread01();
My_thread02 t2=new My_thread02();
t1.start();
t2.start();
t1.join();
t2.join();
out.println("count is "+count);
}
}
方法声明中同步(synchronized )关键字。当它用来修饰一个方法或者一个代码块的时候,能够保证在同一时刻最多只有一个线程执行该段代码。遵循以下五条原则:
一、当两个并发线程访问同一个对象object中的这个synchronized(this)同步代码块时,一个时间内只能有一个线程得到执行。另一个线程必须等待当前线程执行完这个代码块以后才能执行该代码块。
二、然而,当一个线程访问object的一个synchronized(this)同步代码块时,另一个线程仍然可以访问该object中的非synchronized(this)同步代码块。
三、尤其关键的是,当一个线程访问object的一个synchronized(this)同步代码块时,其他线程对object中所有其它synchronized(this)同步代码块的访问将被阻塞。
四、第三个例子同样适用其它同步代码块。也就是说,当一个线程访问object的一个synchronized(this)同步代码块时,它就获得了这个object的对象锁。结果,其它线程对该object对象所有同步代码部分的访问都被暂时阻塞。
五、以上规则对其它对象锁同样适用。
还有,synchronized 锁机制存在重入的特性,就是可以重复获取同一个对象的锁。如下:
public synchronized void methodA(int a, int b);
public synchronized void methodB(int a){
methodA(a, 0);
}
B方法可以执行,就是说B方法获得锁之后,调用的A方法也可以获得该锁。
参考文章——深入理解Java并发之synchronized实现原理
参考文章——synchronized是可重入锁吗?为什么?
区别:
a.Lock使用起来比较灵活,但需要手动释放和开启;采用synchronized不需要用户去手动释放锁,
当synchronized方法或者synchronized代码块执行完之后,系统会自动让线程释放对锁的占用;
b.Lock不是Java语言内置的,synchronized是Java语言的关键字,因此是内置特性。Lock是一个类,通过这个类可以实现同步访问;
c.在并发量比较小的情况下,使用synchronized是个不错的选择,但是在并发量比较高的情况下,其性能下降很严重,此时Lock是个不错的方案。
d.使用Lock的时候,等待/通知 是使用的Condition对象的await()/signal()/signalAll() ,而使用synchronized的时候,则是对象的wait()/notify()/notifyAll();由此可以看出,使用Lock的时候,粒度更细了,一个Lock可以对应多个Condition。
e.虽然Lock缺少了synchronized隐式获取释放锁的便捷性,但是却拥有了锁获取与是释放的可操作性、可中断的获取锁以及超时获取锁等多种synchronized所不具备的同步特性;
作用/功能:
- 保证变量的可见性
volatile可以理解为轻量级的synchronized,它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时,另外一个线程能读到这个修改的值。
- 禁止指令重排序
i++:非原子性的典型例子就是i++.这其实是三条操:
1. 获取i的值
2. i+1
3. 再赋值给i
而volatile修饰的变量在++过程中,如果是多线程访问可能会不是我们预想的样子,多线程访问时是不安全的,出现脏读现象。
拿AtomicLong来说,它既解决了上述的volatile的原子性没有保证的问题,又具有可见性。它是如何做到的?当然就是非阻塞同步算法与CAS(Compare and Swap)无锁算法提到的CAS(比较并交换)指令。 其实AtomicLong的源码里也用到了volatile,但只是用来读取或写入
因为CAS是基于乐观锁的,也就是说当写入的时候,如果寄存器旧值已经不等于现值,说明有其他CPU在修改,那就继续尝试。所以这就保证了操作的原子性。
有几个原则的:
程序次序规则:一个线程内,代码的执行会按照程序书写的顺序
管程锁定原则:对同一变量的unlock操作先行发生于后来的lock操作
volatile变量规则:对一个volatile的写操作先行发生于后来的读操作
线程启动原则:Thread的start()先行发生于线程内的所有动作
线程终止原则:线程内的所有动作都先行发生于线程的终止检测
线程中断原则:对线程调用interrupt()先行发生于被中断的代码检测到是否有中断发生
对象终结原则:一个对象的初始化操作先行发生于finalize()方法
传递性:A先行发生于B,B先行发生于C,那么A先行发生于C
特别注意:
1. ThreadLocal实例 = 类中的private、static字段
2. 只需实例化对象一次 & 不需知道它是被哪个线程实例化
3. 每个线程都保持 对其线程局部变量副本 的隐式引用
4. 线程消失后,其线程局部实例的所有副本都会被垃圾回收(除非存在对这些副本的其他引用)
5. 虽然所有的线程都能访问到这个ThreadLocal实例,但是每个线程只能访问到自己通过调用ThreadLocal的set()设置的值
即 哪怕2个不同的线程在同一个`ThreadLocal`对象上设置了不同的值,他们仍然无法访问到对方的值
核心原理
ThreadLocal类中有1个Map(称:ThreadLocalMap):用于存储每个线程 & 该线程设置的存储在ThreadLocal变量的值
ThreadLocalMap的键Key 当前ThreadLocal实例、值value 该线程设置的存储在ThreadLocal变量的值
该key是 ThreadLocal对象的弱引用;当要抛弃掉ThreadLocal对象时,垃圾收集器会忽略该 key的引用而清理掉ThreadLocal对象
ThreadLocal如何做到线程安全
1.每个线程拥有自己独立的ThreadLocals变量(指向ThreadLocalMap对象 )
2.每当线程 访问 ThreadLocals变量时,访问的都是各自线程自己的ThreadLocalMap变量(键 - 值)
3.ThreadLocalMap变量的键 key 唯一 当前ThreadLocal实例
上述3点 保证了线程间的数据访问隔离,即线程安全
使用注意事项
参考文章——ThreadLocal使用原理、注意问题、使用场景
1、newCachedThreadPool
作用:创建一个可根据需要创建新线程的线程池,但是在以前构造的线程可用时将重用它们,并在需要时使用提供的 ThreadFactory 创建新线程。
特征:
(1)线程池中数量没有固定,可达到最大值(Interger. MAX_VALUE)
(2)线程池中的线程可进行缓存重复利用和回收(回收默认时间为1分钟)
(3)当线程池中,没有可用线程,会重新创建一个线程
创建方式: Executors.newCachedThreadPool();
2、newFixedThreadPool
作用:创建一个可重用固定线程数的线程池,以共享的无界队列方式来运行这些线程。在任意点,在大多数 nThreads 线程会处于处理任务的活动状态。如果在所有线程处于活动状态时提交附加任务,则在有可用线程之前,附加任务将在队列中等待。如果在关闭前的执行期间由于失败而导致任何线程终止,那么一个新线程将代替它执行后续的任务(如果需要)。在某个线程被显式地关闭之前,池中的线程将一直存在。
特征:
(1)线程池中的线程处于一定的量,可以很好的控制线程的并发量
(2)线程可以重复被使用,在显示关闭之前,都将一直存在
(3)超出一定量的线程被提交时候需在队列中等待
创建方式:
(1)Executors.newFixedThreadPool(int nThreads);//nThreads为线程的数量
(2)Executors.newFixedThreadPool(int nThreads,ThreadFactory threadFactory);//nThreads为线程的数量,threadFactory创建线程的工厂方式
3、newSingleThreadExecutor
作用:创建一个使用单个 worker 线程的 Executor,以无界队列方式来运行该线程。(注意,如果因为在关闭前的执行期间出现失败而终止了此单个线程,那么如果需要,一个新线程将代替它执行后续的任务)。可保证顺序地执行各个任务,并且在任意给定的时间不会有多个线程是活动的。与其他等效的 newFixedThreadPool(1) 不同,可保证无需重新配置此方法所返回的执行程序即可使用其他的线程。
特征:
(1)线程池中最多执行1个线程,之后提交的线程活动将会排在队列中以此执行
创建方式:
(1)Executors.newSingleThreadExecutor() ;
(2)Executors.newSingleThreadExecutor(ThreadFactory threadFactory);// threadFactory创建线程的工厂方式
4、newScheduleThreadPool
作用: 创建一个线程池,它可安排在给定延迟后运行命令或者定期地执行。
特征:
(1)线程池中具有指定数量的线程,即便是空线程也将保留
(2)可定时或者延迟执行线程活动
创建方式:
(1)Executors.newScheduledThreadPool(int corePoolSize);// corePoolSize线程的个数
(2)newScheduledThreadPool(int corePoolSize, ThreadFactory threadFactory);// corePoolSize线程的个数,threadFactory创建线程的工厂
5、newSingleThreadScheduledExecutor
作用: 创建一个单线程执行程序,它可安排在给定延迟后运行命令或者定期地执行。
特征:
(1)线程池中最多执行1个线程,之后提交的线程活动将会排在队列中以此执行
(2)可定时或者延迟执行线程活动
创建方式:
(1)Executors.newSingleThreadScheduledExecutor() ;
(2)Executors.newSingleThreadScheduledExecutor(ThreadFactory threadFactory) ;//threadFactory创建线程的工厂
扩展
实际项目中通常会选择创建哪种线程池?为什么?
newSingleThreadExecutor()和newFixedThreadPool(1)异同点?
线程池中的线程如何判断是否空闲?
二、线程池的优势
现在不管是Java线程池,还是数据库连接池,redis缓存连接池,包括dubbo的线程池等等都是为了复用线程,避免频繁的创建和销毁线程浪费大量的系统资源,增加并发编程的风险。
线程池的作用:
控制线程,通过控制线程来控制最大并发数
实现任务线程队列缓存策略和拒绝机制。
实现某些与时间相关的功能,如定时任务,周期执行等。
隔离线程环境,一个线程专门执行耗时任务,另外一个线程执行响应要求高的任务。
三、线程池核心参数
线程池的核心参数是面试的一个重点!!!!
一般通过创建java.util.concurrent.ThreadPoolExecutor对象来创建线程池。
第一个参数:corePoolSize: 核心常驻线程池。如果等于0,任务执行完,没有任何请求进入则销毁线程;如果大于0,即使本地任务执行完毕,核心线程池也不会被销毁。这个参数设置非常关键设置过大浪费资源,设置过小导致线程频繁创建或销毁。
第2个参数:maximumPoolSize:线程池同时执行的最大现场等是maximumPoolSize表示线程池能够容纳同时执行的最大线程数。
> If there are more than corePoolSize but less than maximumPoolSize threads running, a new thread will be created only if the queue is full.
如果线程池中的线程数大于核心线程数且队列满了,且线程数小于最大线程数,则会创建新的线程。
这一块参见源码:java.util.concurrent.ThreadPoolExecutor#execute
如果maximumPoolSize与corePoolSize相等,即是固定大小线程池。
第3个参数:keepAliveTime表示线程池中的线程空闲时间,当空闲时间达到keepAliveTime值时,线程会被销毁,直到只剩下corePoolSize个线程为止,避免浪费内存和句柄资源。
在默认情况下,当线程池的线程数大于corePoolSize时,keepAliveTime才会起作用。
但是当ThreadPoolExecutor的allowCoreThreadTimeOut变量设置为true时,核心线程超时后也会被回收。
第4个参数: TimeUnit表示时间单位。keepAliveTime 的时间单位通常是TimeUnit.SECONDS。
第5个参数: workQueue 表示缓存队列。当请求的线程数大于maximumPoolSize时,线程进入BlockingQueue阻塞队列。后续示例代码中使用的LinkedBlockingQueue是单向链表,使用锁来控制入队和出队的原子性,两个锁分别控制元素的添加和获取,
是一个生产消费模型队列。
第6个参数: threadFactory 表示线程工厂。它用来生产一组相同任务的线程。线程池的命名是通过给这个factory增加组名前缀来实现的。在虚拟机栈分析时,就可以知道线程任务是由哪个线程工厂产生的。
第7个参数: handler 表示执行拒绝策略的对象。当超过第5个参数workQueue的任务缓存区上限的时候,就可以通过该策略处理请求,这是一种简单的限流保护。
参考文章——Java手写线程池的实现方法
参考文章—— 线程池好处和核心参数等面试必备
参考文章——Java ThreadPoolExecutor的拒绝策略
反射 (Reflection) 是 Java 的特征之一,它允许运行中的 Java 程序获取自身的信息,并且可以操作类或对象的内部属性。
简而言之,通过反射,我们可以在运行时获得程序或程序集中每一个类型的成员和成员的信息。程序中一般的对象的类型都是在编译期就确定下来的,而 Java 反射机制可以动态地创建对象并调用其属性,这样的对象的类型在编译期是未知的。所以我们可以通过反射机制直接创建对象,即使这个对象的类型在编译期是未知的。
反射的核心是 JVM 在运行时才动态加载类或调用方法/访问属性,它不需要事先(写代码的时候或编译期)知道运行对象是谁。
缺点:
由于反射会额外消耗一定的系统资源,因此如果不需要动态地创建一个对象,那么就不需要用反射。
另外,反射调用方法时可以忽略权限检查,因此可能会破坏封装性而导致安全问题。
参考文章
ThreadLocal
使用并行去遍历时,数据会被分成多个段,其中每一个都在不同的线程中处理,然后将结果一起输出。Stream 的并行操作依赖于 Java7 中引入的 Fork/Join 框架(JSR166y)来拆分任务和加速处理过程。Java 的并行 API 演变历程基本如下:
1.0-1.4 中的 java.lang.Thread
5.0 中的 java.util.concurrent
6.0 中的 Phasers 等
7.0 中的 Fork/Join 框架
8.0 中的 Lambda
Stream 的另外一大特点是,数据源本身可以是无限的。
存在的隐患:
并行地任务,结果返回时间较长时,会造成ForkJoinPool中的线程池连接会很快用完。
参考文章
Java API针对集合类型排序提供了两种支持:
java.util.Collections.sort(java.util.List)
java.util.Collections.sort(java.util.List, java.util.Comparator)
第一个方法要求所排序的元素类必须实现java.lang.Comparable接口。
第二个方法要求实现一个java.util.Comparator接口。
修饰词 | 类内部 | 本包 | 子类 | 外部包 |
---|---|---|---|---|
public | 1 | 1 | 1 | 1 |
protected | 1 | 1 | 1 | 0 |
default | 1 | 1 | 0 | 0 |
private | 1 | 0 | 0 | 0 |
参考文章——浅谈Java内部类(超详细代码示例)
TreeMap 和 TreeSet 是 Java Collection Framework 的两个重要成员,其中 TreeMap 是 Map 接口的常用实现类,而 TreeSet 是 Set 接口的常用实现类。虽然 TreeMap 和TreeSet 实现的接口规范不同,但 TreeSet 底层是通过 TreeMap 来实现的(如同HashSet底层是是通过HashMap来实现的一样),因此二者的实现方式完全一样。而 TreeMap 的实现就是红黑树算法
相同点
TreeMap和TreeSet都是非同步集合,因此他们不能在多线程之间共享,不过可以使用方法Collections.synchroinzedMap()来实现同步
运行速度都要比Hash集合慢,他们内部对元素的操作时间复杂度为O(logN),而HashMap/HashSet则为O(1)。
TreeMap和TreeSet都是有序的集合,也就是说他们存储的值都是拍好序的。
不同点
最主要的区别就是TreeSet和TreeMap分别实现Set和Map接口
TreeSet只存储一个对象,而TreeMap存储两个对象Key和Value(仅仅key对象有序)
TreeSet中不能有重复对象,而TreeMap中可以存在
TreeMap的底层采用红黑树的实现,完成数据有序的插入,排序。
参考文章——TreeMap和TreeSet的区别与联系
对ClassLoader的理解
类加载器对于所加载类的影响
JVM加载类的两种方式:
Class Loader的类结构层次
启动类加载器(Bootstrap Class Loader):用C++实现的类加载器
是虚拟机的一部分主要加载JVM自身工作需要的类,完全由JVM控制,开发者无法访问.(无法被Java代码引用)
将指定目录下的符合虚拟机规范的类加载到虚拟机内存中,默认是\lib
拓展类加载器(Extension Class Loader):
负责加载\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用拓展类加载器
应用程序加载器(Application Class Loader):由于这个类加载器是Class Loader只能怪的getSystemClassLoder()方法的返回值,所以又称系统加载器
它负责加载classPath路径上的指定的类库 ,如果程序中没有定义过类加载器,一般作为默认的类加载器
参考文章——深入理解Java类加载器(ClassLoader)
参考文章——JVM基础(一) ClassLoader的工作机制
内存结构
内存模型
在计算机世界中, 为了保证共享内存的正确性(原子性、可见性、有序性), 内存模型定义了共享内存系统中多线程程序读写操作行为的规范。通过这些规则来规范对内存的读写操作, 从而保证指令执行的正确性。它与处理器有关、与缓存有关、与并发有关、有编译有关。它解决了CPU多级缓存、处理器优化、指令重排等导致的访问问题, 保证了并发场景下的有序性、一致性、原子性。
内存模型解决并发问题主要采用两种方式: 限制处理器优化和使用内存屏障。
我们知道, Java的多线程之间是通过共享内存进行通信的, 而由于采用共享内存进行通信, 在通信过程中会存在一系列如可见性、原子性、顺序性等问题, 而JMM(Java Memory Model)就是围绕着多线程通信以及与其相关的一系列特性而建立的模型。它只是一个抽象的概念, 是一种符合内存模型规范的,屏蔽了各种硬件和操作系统的访问差异的,保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。JMM定义了一些语法集, 这些语法集映射到Java语言中就是volatile、synchronized等关键字。
程序无法再引用到该对象,那么这个对象就肯定可以被回收,这个状态称为不可达。当对象不可达,该对象就可以作为回收对象被垃圾回收器回收。
那么这个可达还是不可达如何判断呢?
答案就是GC roots ,也就是根对象,如果从一个对象没有到达根对象的路径,或者说从根对象开始无法引用到该对象,该对象就是不可达的。
以下三类对象在jvm中作为GC roots,来判断一个对象是否可以被回收(通常来说我们只要知道虚拟机栈和静态引用就够了)虚拟机栈(JVM stack)中引用的对象(准确的说是虚拟机栈中的栈帧(frames)) ,我们知道,
每个方法执行的时候,jvm都会创建一个相应的栈帧(栈帧中包括操作数栈、局部变量表、运行时常量池的引用),栈帧中包含这在方法内部使用的所有对象的引用(当然还有其他的基本类型数据),当方法执行完后,该栈帧会从虚拟机栈中弹出,这样一来,临时创建的对象的引用也就不存在了,或者说没有任何gc roots指向这些临时对象,这些对象在下一次GC时便会被回收掉。
方法区中类静态属性引用的对象:静态属性是该类型(class)的属性,不单独属于任何实例,因此该属性自然会作为gc roots。只要这个class存在,该引用指向的对象也会一直存在。class 也是会被回收的,在面后说明本地方法栈(Native Stack)引用的对象。
一个class要被回收准确的说应该是卸载,必须同时满足以下三个条件:
堆中不存在该类的任何实例;
加载该类的classloader已经被回收
该类的java.lang.Class对象没有在任何地方被引用,也就是说无法通过反射再带访问该类的信息。
其实这四类引用的区别就在于GC时是否回收该对象
强引用(Strong) 就是我们平时使用的方式 A a = new A();强引用的对象是不会被回收的;
软引用(Soft) 在jvm要内存溢出(OOM)时,会回收软引用的对象,释放更多内存
弱引用(Weak) 在下次GC时,弱引用的对象是一定会被回收的;
虚引用(Phantom) 对对象的存在时间没有任何影响,也无法引用对象实力,唯一的作用就是在该对象被回收时收到一个系统通知。
1. java 堆溢出
java堆用于存储对象实例,只要不断地创建对象,并且这些对象不会被回收(什么情况对象不会被回收呢?
如:由于GC Root到对象之间有可达路径,所以垃圾回收机制不会清除这些对象),那么,当对象的数量达到一定的数量,
从而达到了最大堆容量(-Xmx)限制了,这个时候会产生内存溢出异常。
java堆内存溢出异常的堆栈信息“java.lang.OutOfMemoryError:java heap space”
那么如何解决呢?
首先要确认内存中的对象是否是必要的,也就是要区分出现的是内存泄露(Memory Leak)还是内存溢出(Memory Overflow)如果是内存泄露,
要使用工具查看泄露对象到GC Roots的引用链,找到泄露对象是通过怎样的路径与GC Roots相关联并导致垃圾收集器无法自动回收它们。
如果不是内存泄露,那么就要检查JVM参数(-Xmx与-Xms),根据机器物理内存情况看看是否能把参数调大一些,
另一方面,从代码层面考虑,看看是否存在某些对象生命周期过长、持有状态时间过长的情况,优化代码,从而尝试减少程序在运行期的内存消耗。
2. java栈溢出
JVM中有虚拟机栈和本地方法栈,栈容量由-Xss参数来设置
在java虚拟机规范中描述两种异常:
1)如果线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常
2)如果虚拟机在扩展栈时无法申请足够的内存空间,则抛出OutOfMemoryError异常
那么什么时候可能会抛出上面两种异常呢?
a. 一般来说, 在单线程下,无论是由于栈帧太大还是虚拟机栈容量太小,当内存无法分配的时候,虚拟机抛出的都是StackOverflowError异常。
b. 程序在不断的创建线程,这可能会产生OutOfMemoryError异常,但是此种情况与栈空间是否足够大并没有任何关系
下面来分析一下情况b
b这种情况,为每个线程的栈分配的内存越大,反而越容易产生内存溢出异常
为什么呢?
原因:操作系统分配给每个进程的内存是有限的(32位Windows限制为2GB),虚拟机提供参数来设置java堆和方法区这两部分内存的最大值,
剩余内存 = 2GB - Xmx(最大堆容量) - MaxPermSize(最大方法区容量)
(程序计数器消耗的内存忽略,因为很小)
那么,可以创建线程的数量可以表示为:
可以创建线程的数量 = 剩余内存 / 线程的容量
所有,若每个线程分配的栈容量(-Xss)越大,可以创建的线程数量就越小
那么,不断的创建线程,把剩余内存逐渐耗尽,当剩余内存不足时,就会抛出OutOfMemoryError异常。
“java.lang.OutOfMemoryError:unable to create new native thread”
如何解决呢?
对于情况a,一般来说是不会出现的,(虚拟机默认参数,栈深度一般情况下可以达到1000-2000没有问题,正常的方法调用,这个深度足够了)
对于情况b,解决办法一个是减少线程数量,若不能减少线程数量,那么考虑“减少内存”的手段来解决,即通过减少最大堆和减少栈容量来换取更多的线程
3. 方法区和运行时常量池溢出
首先,了解一下,在JDK1.6及之前的版本中,常量池分配在永久带内,可以通过-XX:PermSize和-XX:MaxPermSize限制方法区的大小,从而间接来限制常量池的大小,
“java.lang.OutOfMemoryError:PermGen space”
JDK1.7开始逐步“去永久代”...,常量池移到了堆中
4. 直接内存溢出
DirectMemory容量默认值与java堆最大值(-Xmx)一样大,也可以通过-XX:MaxDirectMemorySize指定
由DirectMemory导致的内存溢出,可以考虑一下是不是由于程序中使用了NIO导致的,进行排查
概念:
新生代 GC(Minor GC):指发生在新生代的垃圾收集动作,因为 Java 对象大多都具备朝生夕灭的特性,
所以 Minor GC 非常频繁,一般回收速度也比较快。
老年代 GC(Major GC / Full GC):指发生在老年代的 GC,出现了 Major GC,经常会伴随至少一次的
Minor GC(但非绝对的,在 ParallelScavenge 收集器的收集策略里就有直接进行 Major GC 的策略选择
过程) 。MajorGC 的速度一般会比 Minor GC 慢 10倍以上。
Minor GC触发机制:
当年轻代满时就会触发Minor GC,这里的年轻代满指的是Eden代满,Survivor满不会引发GC
Full GC触发机制:
当年老代满时会引发Full GC,Full GC将会同时回收年轻代、年老代,
当永久代满时也会引发Full GC,会导致Class、Method元信息的卸载
判断Java中对象存活的算法
1.引用计数器算法:
引用计数器算法是给每个对象设置一个计数器,当有地方引用这个对象的时候,计数器+1,当引用失效的时候,计数器-1,当计数器为0的时候,JVM就认为对象不再被使用,是“垃圾”了。
引用计数器实现简单,效率高;但是不能解决循环引用问问题(A对象引用B对象,B对象又引用A对象,但是A,B对象已不被任何其他对象引用),同时每次计数器的增加和减少都带来了很多额外的开销,所以在JDK1.1之后,这个算法已经不再使用了。
2.根搜索方法:
根搜索方法是通过一些“GCRoots”对象作为起点,从这些节点开始往下搜索,搜索通过的路径成为引用链(ReferenceChain),当一个对象没有被GCRoots的引用链连接的时候,说明这个对象是不可用的。
GCRoots对象包括:
虚拟机栈(栈帧中的本地变量表)中的引用的对象。
方法区域中的类静态属性引用的对象。
方法区域中常量引用的对象。
本地方法栈中JNI(Native方法)的引用的对象。
1. 复制算法
复制算法可以解决效率问题,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块,当这一块内存用完了,就将还存活着的对象复制到另一块上面,然后再把已经使用过的内存空间一次清理掉,这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可(还可使用TLAB进行高效分配内存)。
优点
效率高,没有内存碎片
缺点:
1、浪费一半的内存空间
2、复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。
2. 标记清除算法
标记-清除(Mark-Sweep)算法是现代垃圾回收算法的思想基础。标记-清除算法将垃圾回收分为两个阶段:标记阶段和清除阶段。一种可行的实现是,在标记阶段,首先通过根节点,标记所有从根节点开始的可达对象。因此,未被标记的对象就是未被引用的垃圾对象(好多资料说标记出要回收的对象,其实明白大概意思就可以了)。然后,在清除阶段,清除所有未被标记的对象。
缺点:
1、效率问题,标记和清除两个过程的效率都不高;
2、空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大的对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
3. 标记整理算法
标记整理算法类似与标记清除算法,不过它标记完对象后,不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉边界以外的内存。
缺点:
1、效率问题,(同标记清除算法)标记和整理两个过程的效率都不高;
优点:
1、相对标记清除算法,解决了内存碎片问题。
2、没有内存碎片后,对象创建内存分配也更快速了(可以使用TLAB进行分配)。
4. 分代收集算法
当前商业虚拟机都是采用分代收集算法,它根据对象存活周期的不同将内存划分为几块,一般是把Java堆分为新生代和老年代,然后根据各个年代的特点采用最适当的收集算法,在新生代中,每次垃圾收集都发现有大批对象死去,只有少量存活,就选用复制算法,而老年代因为对象存活率高,没有额外空间对它进行分配担保,就必须使用“标记清理”或者“标记整理”算法来进行回收。
对象分配策略:
1. 对象优先在Eden区域分配,如果对象过大直接分配到Old区域。
2. 长时间存活的对象进入到Old区域。的转载都请联系作者获得授权并注明出处。
参考文章
Serial GC,它是最古老的垃圾收集器,“Serial”体现在其收集工作是单线程的,并且在进行垃圾收集过程中,会进入臭名昭著的“Stop-The-World”状态。当然,其单线程设计也意味着精简的 GC 实现,无需维护复杂的数据结构,初始化也简单,所以一直是 Client 模式下 JVM 的默认选项。
从年代的角度,通常将其老年代实现单独称作 Serial Old,它采用了标记 - 整理(Mark-Compact)算法,区别于新生代的复制算法。
Serial GC 的对应 JVM 参数是:
-XX:+UseSerialGC
ParNew GC,很明显是个新生代 GC 实现,它实际是 Serial GC 的多线程版本,最常见的应用场景是配合老年代的 CMS GC 工作,下面是对应参数
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
CMS(Concurrent Mark Sweep) GC,基于标记 - 清除(Mark-Sweep)算法,设计目标是尽量减少停顿时间,这一点对于 Web 等反应时间敏感的应用非常重要,一直到今天,仍然有很多系统使用 CMS GC。但是,CMS 采用的标记 - 清除算法,存在着内存碎片化问题,所以难以避免在长时间运行等情况下发生 full GC,导致恶劣的停顿。另外,既然强调了并发(Concurrent),CMS 会占用更多 CPU 资源,并和用户线程争抢。
Parrallel GC,在早期 JDK 8 等版本中,它是 server 模式 JVM 的默认 GC 选择,也被称作是吞吐量优先的 GC。它的算法和 Serial GC 比较相似,尽管实现要复杂的多,其特点是新生代和老年代 GC 都是并行进行的,在常见的服务器环境中更加高效。
开启选项是:
-XX:+UseParallelGC
另外,Parallel GC 引入了开发者友好的配置项,我们可以直接设置暂停时间或吞吐量等目标,JVM 会自动进行适应性调整,例如下面参数:
-XX:MaxGCPauseMillis=value -XX:GCTimeRatio=N // GC 时间和用户时间比例 = 1 / (N+1)
G1 GC 这是一种兼顾吞吐量和停顿时间的 GC 实现,是 Oracle JDK 9 以后的默认 GC 选项。G1 可以直观的设定停顿时间的目标,相比于 CMS GC,G1 未必能做到 CMS 在最好情况下的延时停顿,但是最差情况要好很多。
G1 GC 仍然存在着年代的概念,但是其内存结构并不是简单的条带式划分,而是类似棋盘的一个个 region。Region 之间是复制算法,但整体上实际可看作是标记 - 整理(Mark-Compact)算法,可以有效地避免内存碎片,尤其是当 Java 堆非常大的时候,G1 的优势更加明显。
G1 吞吐量和停顿表现都非常不错,并且仍然在不断地完善,与此同时 CMS 已经在 JDK 9 中被标记为废弃(deprecated),所以 G1 GC 值得你深入掌握
2、CPU占用过高问题定位
2.1、定位问题进程
使用top命令查看资源占用情况
2.2、定位问题线程
使用ps -mp pid -o THREAD,tid,time命令查看该进程的线程情况
2.3、查看问题线程堆栈
挑选TID为14065的线程,查看该线程的堆栈情况,先将线程id转为16进制,使用printf "%x\n" tid命令进行转换
2.4、根据线程ID的十六进制值grep,使用jstack命令打印线程堆栈信息,命令格式:jstack pid |grep tid -A 30
3、内存问题定位
3.1、使用jstat -gcutil命令查看进程的内存情况
3.2、分析堆栈
使用jstack命令查看进程的堆栈情况
[ylp@ylp-web-01 ~]$ jstack 14063 >>jstack.out
3.3、代码定位
[参考文章](线上服务 CPU 很高该怎么做?有哪些措施可以找到问题?)
回答思路:1.先用通俗易懂的话解释下何为IOC和AOP---》2.各自的实现原理---》3.自己的项目中如何使用
1.IOC
许多应用都是通过彼此间的相互合作来实现业务逻辑的,如类A要调用类B的方法,以前我们都是在类A中,通过自身new一个类B,然后在调用类B的方法,现在我们把new类B的事情交给spring来做,在我们调用的时候,容器会为我们实例化。
2. IOC容器的初始化过程
资源定位,即定义bean的xml---》载入---》IOC容器注册,注册beanDefinition
IOC容器的初始化过程,一般不包含bean的依赖注入的实现,在spring IOC设计中,bean的注册和依赖注入是两个过程,,依赖注入一般发生在应用第一次索取bean的时候,但是也可以在xm中配置,在容器初始化的时候,这个bean就完成了初始化。
3. 三种注入方式,构造器、接口、set注入,我们常用的是set注入
4. bean是如何创建---工厂模式
5. 数据是如何注入---反射
6.AOP
面向切面编程,在我们的应用中,经常需要做一些事情,但是这些事情与核心业务无关,比如,
要记录所有update*方法的执行时间时间,操作人等等信息,记录到日志,通过spring的AOP技术,
就可以在不修改update*的代码的情况下完成该需求。
7.AOP的实现原理---代理
参考文章
Ioc的原理
Aop的实现原理
1. 实例化Bean对于BeanFactory容器,当客户向容器请求一个尚未初始化的bean时,或初始化bean的时候需要注入另一个尚未初始化的依赖时,容器就会调用createBean进行实例化。 对于ApplicationContext容器,当容器启动结束后,便实例化所有的bean。 容器通过获取BeanDefinition对象中的信息进行实例化。并且这一步仅仅是简单的实例化,并未进行依赖注入。 实例化对象被包装在BeanWrapper对象中,BeanWrapper提供了设置对象属性的接口,从而避免了使用反射机制设置属性。
2. 设置对象属性(依赖注入)实例化后的对象被封装在BeanWrapper对象中,并且此时对象仍然是一个原生的状态,并没有进行依赖注入。 紧接着,Spring根据BeanDefinition中的信息进行依赖注入。 并且通过BeanWrapper提供的设置属性的接口完成依赖注入。
3. 注入Aware接口紧接着,Spring会检测该对象是否实现了xxxAware接口,并将相关的xxxAware实例注入给bean。
4. BeanPostProcessor当经过上述几个步骤后,bean对象已经被正确构造,但如果你想要对象被使用前再进行一些自定义的处理,就可以通过BeanPostProcessor接口实现。 该接口提供了两个函数:postProcessBeforeInitialzation( Object bean, String beanName ) 当前正在初始化的bean对象会被传递进来,我们就可以对这个bean作任何处理。 这个函数会先于InitialzationBean执行,因此称为前置处理。 所有Aware接口的注入就是在这一步完成的。postProcessAfterInitialzation( Object bean, String beanName ) 当前正在初始化的bean对象会被传递进来,我们就可以对这个bean作任何处理。 这个函数会在InitialzationBean完成后执行,因此称为后置处理。
5. InitializingBean与init-method当BeanPostProcessor的前置处理完成后就会进入本阶段。 InitializingBean接口只有一个函数:afterPropertiesSet()这一阶段也可以在bean正式构造完成前增加我们自定义的逻辑,但它与前置处理不同,由于该函数并不会把当前bean对象传进来,因此在这一步没办法处理对象本身,只能增加一些额外的逻辑。 若要使用它,我们需要让bean实现该接口,并把要增加的逻辑写在该函数中。然后Spring会在前置处理完成后检测当前bean是否实现了该接口,并执行afterPropertiesSet函数。当然,Spring为了降低对客户代码的侵入性,给bean的配置提供了init-method属性,该属性指定了在这一阶段需要执行的函数名。Spring便会在初始化阶段执行我们设置的函数。init-method本质上仍然使用了InitializingBean接口。
6. DisposableBean和destroy-method和init-method一样,通过给destroy-method指定函数,就可以在bean销毁前执行指定的逻辑。
@Component, @Service, @Controller, @Repository是spring注解,注解后可以被spring框架所扫描并注入到spring容器来进行管理
@Component是通用注解,其他三个注解是这个注解的拓展,并且具有了特定的功能
@Repository注解在持久层中,具有将数据库操作抛出的原生异常翻译转化为spring的持久层异常的功能。
@Controller层是spring-mvc的注解,具有将请求进行转发,重定向的功能。
@Service层是业务逻辑层注解,这个注解只是标注该类处于业务逻辑层。
用这些注解对应用进行分层之后,就能将请求处理,义务逻辑处理,数据库操作处理分离出来,为代码解耦,也方便了以后项目的维护和开发。
@Autowired默认按类型装配,默认情况下必须要求依赖对象必须存在,如果要允许null值,可以设置它的required属性为false,例如:@Autowired(required=false) ,如果我们想使用名称装配可以结合@Qualifier注解进行使用
@Resource,默认按照名称进行装配,名称可以通过name属性进行指定,如果没有指定name属性,当注解写在字段上时,默认取字段名进行安装名称查找,如果注解写在setter方法上默认取属性名进行装配。当找不到与名称匹配的bean时才按照类型进行装配。但是需要注意的是,如果name属性一旦指定,就只会按照名称进行装配。
Spring事务的本质其实就是数据库对事务的支持,没有数据库的事务支持,spring是无法提供事务功能的。对于纯JDBC操作数据库,想要用到事务,可以按照以下步骤进行:
获取连接 Connection con = DriverManager.getConnection()
开启事务con.setAutoCommit(true/false);
执行CRUD
提交事务/回滚事务 con.commit() / con.rollback();
关闭连接 conn.close();
使用Spring的事务管理功能后,我们可以不再写步骤 2 和 4 的代码,而是由Spirng 自动完成。
那么Spring是如何在我们书写的 CRUD 之前和之后开启事务和关闭事务的呢?解决这个问题,也就可以从整体上理解Spring的事务管理实现原理了。下面简单地介绍下,注解方式为例子
配置文件开启注解驱动,在相关的类和方法上通过注解@Transactional标识。
spring 在启动的时候会去解析生成相关的bean,这时候会查看拥有相关注解的类和方法,并且为这些类和方法生成代理,并根据@Transaction的相关参数进行相关配置注入,这样就在代理中为我们把相关的事务处理掉了(开启正常提交事务,异常回滚事务)。
真正的数据库层的事务提交和回滚是通过binlog或者redo log实现的。
在当前含有事务方法内部调用其他的方法(无论该方法是否含有事务),这就属于Spring事务传播机制的知识点范畴了。
Spring事务基于Spring AOP,Spring AOP底层用的动态代理,动态代理有两种方式:
基于接口代理(JDK代理)
基于接口代理,凡是类的方法非public修饰,或者用了static关键字修饰,那这些方法都不能被Spring AOP增强
基于CGLib代理(子类代理)
基于子类代理,凡是类的方法使用了private、static、final修饰,那这些方法都不能被Spring AOP增强
我们知道在一般情况下,只有无状态的Bean才可以在多线程环境下共享,在Spring中,绝大部分Bean都可以声明为singleton作用域。就是因为Spring对一些Bean(如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等)中非线程安全状态的“状态性对象”采用ThreadLocal封装,让它们也成为线程安全的“状态 性对象”,因此,有状态的Bean就能够以singleton的方式在多线程中工作。
常量名称 | 常量解释 |
---|---|
PROPAGATION_REQUIRED | 支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择,也是 Spring 默认的事务的传播。 |
PROPAGATION_REQUIRES_NEW | 新建事务,如果当前存在事务,把当前事务挂起。新建的事务将和被挂起的事务没有任何关系,是两个独立的事务,外层事务失败回滚之后,不能回滚内层事务执行的结果,内层事务失败抛出异常,外层事务捕获,也可以不处理回滚操作 |
PROPAGATION_SUPPORTS | 支持当前事务,如果当前没有事务,就以非事务方式执行。 |
PROPAGATION_MANDATORY | 支持当前事务,如果当前没有事务,就抛出异常。 |
PROPAGATION_NOT_SUPPORTED | 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。 |
PROPAGATION_NEVER | 以非事务方式执行,如果当前存在事务,则抛出异常。 |
PROPAGATION_NESTED | 如果一个活动的事务存在,则运行在一个嵌套的事务中。如果没有活动事务,则按REQUIRED属性执行。它使用了一个单独的事务,这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。 |
参考文章——深入理解Spring事务的基本原理、传播属性、隔离级别
扩展
Spring事务失效的场景?
select查询到底需不需要事务?
如果你一次执行单条查询语句,则没有必要启用事务支持,数据库默认支持SQL执行期间的读一致性;
如果你一次执行多条查询语句,例如统计查询,报表查询,在这种场景下,多条查询SQL必须保证整体的读一致性,否则,在前条SQL查询之后,后条SQL查询之前,数据被其他用户改变,则该次整体的统计查询将会出现读数据不一致的状态,此时,应该启用事务支持。
部分旧业务块还是Sql Server
新业务服务都采用Mysql
Mysql 5.5之前是采用MyISAM存储引擎,5.5及之后采用InnoDB存储引擎
索引类型 | 叶子节点 | 插入速度 | 优点 |
---|---|---|---|
聚簇索引 | 叶节点就是数据节点 | 慢 | 适合排序 |
非聚族索引 | 叶节点仍然是索引节点,并保留一个链接指向对应数据块 | 快 |
聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。
聚簇索引适合排序,非聚簇索引(也叫二级索引)不适合用在排序的场合。
因为聚簇索引本身已经是按照物理顺序放置的,排序很快。非聚簇索引则没有按序存放,需要额外消耗资源来排序。
当你需要取出一定范围内的数据时,用聚簇索引也比用非聚簇索引好。
另外,二级索引需要两次索引查找,而不是一次才能取到数据,因为存储引擎第一次需要通过二级索引找到索引的叶子节点,从而找到数据的主键,然后在聚簇索引中用主键再次查找索引,再找到数据。
参考文章
拓展
Mysql索引的分类?
参考文章——mysql联合索引
MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构。
数据库查询是数据库的主要功能之一,最基本的查询算法是顺序查找(linear search)时间复杂度为O(n),显然在数据量很大时效率很低。优化的查找算法如二分查找(binary search)、二叉树查找(binary tree search)等,虽然查找效率提高了。但是各自对检索的数据都有要求:二分查找要求被检索数据有序,而二叉树查找只能应用于二叉查找树上,但是数据本身的组织结构不可能完全满足各种数据结构(例如,理论上不可能同时将两列都按顺序进行组织)。所以,在数据之外,数据库系统还维护着满足特定查找算法的数据结构。这些数据结构以某种方式引用(指向)数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构就是索引。
参考文章
拓展
说一下B Tree、B+ Tree、平衡树、红黑树的结构和区别
参考文章——叉树、平衡二叉树、红黑树、B-树、B+树、B*树、T树之间的详解和比较
参考文章——mysql B+树索引
事务
MyISAM是非事务安全型的,而InnoDB是事务安全型的,默认开启自动提交,宜合并事务,一同提交,减小数据库多次提交导致的开销,大大提高性能。
锁
MyISAM锁的粒度是表级,而InnoDB支持行级锁定。
全文索引
MyISAM支持全文类型索引,而InnoDB仅支持B+树索引。
查询效率
MyISAM相对简单,所以在效率上要优于InnoDB,小型应用可以考虑使用MyISAM。
外键
MyISAM不支持外健,InnoDB支持。
count
MyISAM保有表的总行数,InnoDB只能遍历。
保存类型
MyISAM表是保存成文件的形式,在跨平台的数据转移中使用MyISAM存储会省去不少的麻烦。
索引和数据存放
MyIsam索引和数据分离,InnoDB在一起,MyIsam天生非聚簇索引,最多有一个unique的性质,InnoDB的数据文件本身就是主键索引文件,这样的索引被称为“聚簇索引”
具体见:https://blog.csdn.net/silyvin/article/details/80140153
应用场景:
1).MyISAM管理非事务表。它提供高速存储和检索,以及全文搜索能力。如果应用中需要执行大量的SELECT查询,那么MyISAM是更好的选择。
2).InnoDB用于事务处理应用程序,具有众多特性,包括ACID事务支持。如果应用中需要执行大量的INSERT或UPDATE操作,则应该使用InnoDB,这样可以提高多用户并发操作的性能。
参考文章
扩展
MyISAM为什么支持全文索引?
explain select ...
type:
显示sql执行的类型,共12级从最好到最差的类型为system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL。一般来说,type至少要达到range级别,最好达到ref级别,低于range级别的sql必须进行优化。
key:
显示sql执行过程中实际使用的键或索引,如果为null则表示未使用任何索引,必须进行优化。
extra:
如果是Only index,这意味着信息只用索引树中的信息检索出的,这比扫描整个表要快。
如果是where used,就是使用上了where限制。
如果是impossible where 表示用不着where,一般就是没查出来啥。
如果此信息显示Using filesort或者Using temporary的话会很吃力,WHERE和ORDER BY的索引经常无法兼顾,如果按照WHERE来确定索引,那么在ORDER BY时,就必然会引起Using filesort,这就要看是先过滤再排序划算,还是先排序再过滤划算。
事务的四大特性
数据库中事务的四大特性(ACID):原子性、一致性、隔离性、持久性。如果一个数据库声称支持事务的操作,那么该数据库必须要具备以下四个特性:
(1)原子性(Atomicity)
原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚,因此事务的操作如果成功就必须要完全应用到数据库,如果操作失败则不能对数据库有任何影响。
(2)一致性(Consistency)
一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态。
如:拿转账来说,假设用户A和用户B两者的钱加起来一共是5000,那么不管A和B之间如何转账,转几次账,事务结束后两个用户的钱相加起来应该还得是5000,这就是事务的一致性。
(3)隔离性(Isolation)
隔离性是当多个用户并发访问数据库时,比如操作同一张表时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。
即要达到这么一种效果:对于任意两个并发的事务T1和T2,在事务T1看来,T2要么在T1开始之前就已经结束,要么在T1结束之后才开始,这样每个事务都感觉不到有其他事务在并发地执行。
(4)持久性(Durability)
持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
例如:我们在使用JDBC操作数据库时,在提交事务方法后,提示用户事务操作完成,当我们程序执行完成直到看到提示后,就可以认定事务以及正确提交,即使这时候数据库出现了问题,也必须要将我们的事务完全执行完成,否则就会造成我们看到提示事务处理完毕,但是数据库因为故障而没有执行事务的重大错误。
事务的隔离级别
• ① Serializable (串行化):可避免脏读、不可重复读、幻读的发生。
• ② Repeatable read (可重复读):可避免脏读、不可重复读的发生。
• ③ Read committed (读已提交):可避免脏读的发生。
• ④ Read uncommitted (读未提交):最低级别,任何情况都无法保证。
以上四种隔离级别最高的是Serializable级别,最低的是Read uncommitted级别,当然级别越高,执行效率就越低。像Serializable这样的级别,就是以锁表的方式(类似于Java多线程中的锁)使得其他的线程只能在锁外等待,所以平时选用何种隔离级别应该根据实际情况。在MySQL数据库中默认的隔离级别为Repeatable read (可重复读)。
在MySQL数据库中,支持上面四种隔离级别,默认的为Repeatable read (可重复读);而在Oracle数据库中,只支持Serializable (串行化)级别和Read committed (读已提交)这两种级别,其中默认的为Read committed级别。
总结:
后记:其实说来说去也就三方面的概念
1)四大隔离级别:串行化、可重复读、读已提交、读未提交;
2)四大特性(ACID):原子性、一致性、隔离性、持久性;
3)三个问题:脏读、不可重复度、幻读;
参考文章
一、架构层面
1、做主从复制。
2、实现读写分离。
3、分库分表。
二、系统层面
1、增加内存。
2、硬盘使用固态硬盘 SSD。
3、给磁盘做 raid0 或者 raid5 以增加磁盘的读写速度。
4、可以重新挂载磁盘,并加上 noatime 参数,这样可以减少磁盘的 I/O。
三、MySQL本身的优化
1、如果未配置主从同步,可以把 bin-log 功能关闭,减少磁盘 I/O。
2、在 my.cnf 中加上 skip-name-resolve ,这样可以避免由于解析主机名延迟造成 M有SQL 执行慢。
3、调整几个关键的 buffer 和 cache。调整的依据,主要根据数据库的状态来调试。如何调优可以参考五。
4、根据具体的使用场景,选择合适的存储引擎。
四、应用层次
查看慢查询日志,根据慢查询日志优化程序中的 SQL 语句,比如增加索引
五、调整关键的buffer和cache
1、key_buffer_size
首先可以根据系统的内存大小设定它,大概的一个参考值:1G以下内存设定 128M;2G/256M; 4G/384M; 8G/1024M;16G/2048M。这个值可以通过检查状态值 Key_read_requests 和 Key_reads,可以知道 key_buffer_size 设置是否合理。比例 key_reads / key_read_requests 应该尽可能的低,至少是 1:100,1:1000更好(上述状态值可以使用 SHOW STATUS LIKE 'key_read%' 获得)。注意:该参数值设置的过大反而会是服务器整体效率降低!
2、table_open_cache
打开一个表的时候,会临时把表里面的数据放到这部分内存中,一般设置成 1024 就够了,它的大小我们可以通过这样的方法来衡量: 如果你发现 open_tables 等于 table_cache,并且 opened_tables 在不断增长,那么你就需要增加 table_cache 的值了(上述状态值可以使用 SHOW STATUS LIKE 'Open%tables' 获得)。注意,不能盲目地把 table_cache 设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能不稳定或者连接失败。
3、sort_buffer_size
查询排序时所能使用的缓冲区大小,该参数对应的分配内存是每连接独占! 如果有 100 个连接,那么实际分配的总共排序缓冲区大小为100 × 4 = 400MB。所以,对于内存在 4GB 左右的服务器推荐设置为:4-8M。
4、read_buffer_size
读查询操作所能使用的缓冲区大小。和 sort_buffer_size 一样,该参数对应的分配内存也是每连接独享!
5、join_buffer_size
联合查询操作所能使用的缓冲区大小,和 sort_buffer_size 一样,该参数对应的分配内存也是每连接独享!
6、myisam_sort_buffer_size
这个缓冲区主要用于修复表过程中排序索引使用的内存或者是建立索引时排序索引用到的内存大小,一般 4G 内存给 64M 即可。
7、query_cache_size
MySQL查询操作缓冲区的大小,通过以下做法调整:SHOW STATUS LIKE ‘Qcache%’; 如果Qcache_lowmem_prunes该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值,用户可以适当的调整缓存大小。如果该值非常大,则表明经常出现缓冲不够的情况,需要增加缓存大小Qcache_free_memory:查询缓存的内存大小,通过这个参数可以很清晰的知道当前系统的查询内存是否够用,是多了,还是不够用,我们可以根据实际情况做出调整。一般情况下 4G 内存设置 64M 足够了。
8、thread_cache_size
表示可以重新利用保存在缓存中线程的数,参考如下值:1G —> 8; 2G —> 16; 3G —> 32; 3G —> 64
除此之外,还有几个比较关键的参数
9、thread_concurrency
这个值设置为 CPU 核数的2倍即可。
10、wait_timeout
表示空闲的连接超时时间,默认是:28800s,这个参数是和 interactive_timeout 一起使用的,也就是说要想让 wait_timeout 生效,必须同时设置 interactive_timeout,建议他们两个都设置为10。
11、max_connect_errors
是一个 MySQL 中与安全有关的计数器值,它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。与性能并无太大关系。为了避免一些错误我们一般都设置比较大,比如说10000。
12、max_connections
最大的连接数,根据业务请求量适当调整,设置 500 足够。
13、max_user_connections
是指同一个账号能够同时连接到 mysql 服务的最大连接数。设置为 0 表示不限制。通常我们设置为 100 足够。
参考文章
三次握手
四次挥手
常见面试题
【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,
SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,
所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都
发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,
有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK
回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,
它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个
计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的
2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,
2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,
那么Client推断ACK已经被成功接收,则结束TCP连接。
【问题3】为什么不能用两次握手进行连接?
答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),
也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,
假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,
S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,
将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。
在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。
而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。
服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时
还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一
连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
Redis事务通常会使用MULTI,EXEC,WATCH等命令来完成,redis实现事务实现的机制与常见的关系型数据库
有很大的却别,比如redis的事务不支持回滚,事务执行时会阻塞其它客户端的请求执行。
redis事务从开始到结束通常会通过三个阶段:
1.事务开始
2.命令入队
3.事务执行
参考文章
参考文章
水平分表
依据某一列做某些操作(对数字列做求余,对于一些非数字列可先MD5后再取余)拆分表,查分出来的表和原表结构一致。
样例
[外链图片转存失败(img-eF5JrXcG-1567133099747)(https://files.jb51.net/file_images/article/201903/20193195508560.png?20192195518)]
垂直分表
根据查询列的频度,将不需要的一些字段拆分出去组成新表,利用外键关联。表的结构发生变化。
样例
[外链图片转存失败(img-HLdi8hRs-1567133099748)(https://files.jb51.net/file_images/article/201903/20193195508560.png?20192195518)]
分片就是分库+分表,属于水平切分,将表中数据按照某种规则放到多个库中,既分表又分库,就相当于原先一个库中的一个表,现在放到了好多个表里面,然后这好多个表又分散到了好多个库中。分片和分区也不冲突。
答:Spring Cloud是一个基于Spring Boot实现的云应用开发工具;Spring boot专注于快速、方便集成的单个个体,Spring Cloud是关注全局的服务治理框架;spring boot使用了约定大于配置的理念,很多集成方案已经帮你选择好了,能不配置就不配置,Spring Cloud很大的一部分是基于Spring boot来实现。
微服务是可以独立部署、水平扩展、独立访问(或者有独立的数据库)的服务单元,SpringCloud就是这些微服务的大管家,采用了微服务这种架构之后,项目的数量会非常多,Spring Cloud做为大管家就需要提供各种方案来维护整个生态。Spring Cloud就是一套分布式服务治理的框架,既然它是一套服务治理的框架,那么它本身不会提供具体功能性的操作,更专注于服务之间的通讯、熔断、监控等。因此就需要很多的组件来支持一套功能。Spring Boot和Spring Cloud的关系Spring Boot 是 Spring 的一套快速配置脚手架,可以基于Spring Boot 快速开发单个微服务,Spring Cloud是一个基于Spring Boot实现的云应用开发工具;Spring Boot专注于快速、方便集成的单个微服务个体,Spring Cloud关注全局的服务治理框架;Spring Boot使用了默认大于配置的理念,很多集成方案已经帮你选择好了,能不配置就不配置,Spring Cloud很大的一部分是基于Spring Boot来实现,可以不基于Spring Boot吗?不可以。Spring Boot可以离开Spring Cloud独立使用开发项目,但是Spring Cloud离不开Spring Boot,属于依赖的关系
第一种:简单工厂
又叫做静态工厂方法(StaticFactory Method)模式,但不属于23种GOF设计模式之一。
简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。
spring中的BeanFactory就是简单工厂模式的体现,根据传入一个唯一的标识来获得bean对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。如下配置,就是在 HelloItxxz 类中创建一个 itxxzBean。
Hello! 这是singletonBean!
Hello! 这是itxxzBean!
第二种:工厂方法(Factory Method)
通常由应用程序直接使用new创建新的对象,为了将对象的创建和使用相分离,采用工厂模式,即应用程序将对象的创建及初始化职责交给工厂对象。
一般情况下,应用程序有自己的工厂对象来创建bean.如果将应用程序自己的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。
以工厂方法中的静态方法为例讲解一下:
import java.util.Random;
public class StaticFactoryBean {
public static Integer createRandom() {
return new Integer(new Random().nextInt());
}
}
建一个config.xm配置文件,将其纳入Spring容器来管理,需要通过factory-method指定静态方法名称
测试:
public static void main(String[] args) {
//调用getBean()时,返回随机数.如果没有指定factory-method,会返回StaticFactoryBean的实例,即返回工厂Bean的实例
XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml"));
System.out.println("我是IT学习者创建的实例:"+factory.getBean("random").toString());
}
第三种:单例模式(Singleton)
保证一个类仅有一个实例,并提供一个访问它的全局访问点。
spring中的单例模式完成了后半句话,即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例,这是因为spring管理的是任意的java对象。
核心提示点:Spring下默认的bean均为singleton,可以通过singleton=“true|false” 或者 scope=“?”来指定
第四种:适配器(Adapter)
在Spring的Aop中,使用的Advice(通知)来增强被代理类的功能。Spring实现这一AOP功能的原理就使用代理模式(1、JDK动态代理。2、CGLib字节码生成技术代理。)对类进行方法级别的切面增强,即,生成被代理类的代理类, 并在代理类的方法前,设置拦截器,通过执行拦截器中的内容增强了代理方法的功能,实现的面向切面编程。
Adapter类接口:Target
public interface AdvisorAdapter {
boolean supportsAdvice(Advice advice);
MethodInterceptor getInterceptor(Advisor advisor);
}
MethodBeforeAdviceAdapter类,Adapter
class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {
public boolean supportsAdvice(Advice advice) {
return (advice instanceof MethodBeforeAdvice);
}
public MethodInterceptor getInterceptor(Advisor advisor) {
MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
return new MethodBeforeAdviceInterceptor(advice);
}
}
第五种:包装器(Decorator)
在我们的项目中遇到这样一个问题:我们的项目需要连接多个数据库,而且不同的客户在每次访问中根据需要会去访问不同的数据库。我们以往在spring和hibernate框架中总是配置一个数据源,因而sessionFactory的dataSource属性总是指向这个数据源并且恒定不变,所有DAO在使用sessionFactory的时候都是通过这个数据源访问数据库。但是现在,由于项目的需要,我们的DAO在访问sessionFactory的时候都不得不在多个数据源中不断切换,问题就出现了:如何让sessionFactory在执行数据持久化的时候,根据客户的需求能够动态切换不同的数据源?我们能不能在spring的框架下通过少量修改得到解决?是否有什么设计模式可以利用呢?
首先想到在spring的applicationContext中配置所有的dataSource。这些dataSource可能是各种不同类型的,比如不同的数据库:Oracle、SQL Server、MySQL等,也可能是不同的数据源:比如apache 提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean等。然后sessionFactory根据客户的每次请求,将dataSource属性设置成不同的数据源,以到达切换数据源的目的。
spring中用到的包装器模式在类名上有两种表现:一种是类名中含有Wrapper,另一种是类名中含有Decorator。基本上都是动态地给一个对象添加一些额外的职责。
第六种:代理(Proxy)
为其他对象提供一种代理以控制对这个对象的访问。 从结构上来看和Decorator模式类似,但Proxy是控制,更像是一种对功能的限制,而Decorator是增加职责。
spring的Proxy模式在aop中有体现,比如JdkDynamicAopProxy和Cglib2AopProxy。
第七种:观察者(Observer)
定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。
spring中Observer模式常用的地方是listener的实现。如ApplicationListener。
第八种:策略(Strategy)
定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。
spring中在实例化对象的时候用到Strategy模式
在SimpleInstantiationStrategy中有如下代码说明了策略模式的使用情况:
第九种:模板方法(Template Method)
定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Template Method模式一般是需要继承的。这里想要探讨另一种对Template Method的理解。spring中的JdbcTemplate,在用这个类时并不想去继承这个类,因为这个类的方法太多,但是我们还是想用到JdbcTemplate已有的稳定的、公用的数据库连接,那么我们怎么办呢?我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码,而且这段代码会用到JdbcTemplate中的变量。怎么办?那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法,我们去实现这个方法,就把变化的东西集中到这里了。然后我们将这个回调对象传入到JdbcTemplate,从而完成了调用。这可能是Template Method不需要继承的另一种实现方式吧。
以下是一个具体的例子:
JdbcTemplate中的execute方法
参考文章
图中,客户端的一个接口,需要调用服务A-N。客户端必须要知道所有服务的网络位置的,以往的做法是配置是配置文件中,或者有些配置在数据库中。这里就带出几个问题:
需要配置N个服务的网络位置,加大配置的复杂性
服务的网络位置变化,都需要改变每个调用者的配置
集群的情况下,难以做负载(反向代理的方式除外)
总结起来一句话:服务多了,配置很麻烦,问题多多
与之前一张不同的是,加了个服务发现模块。图比较简单,这边文字描述下。服务A-N把当前自己的网络位置注册到服务发现模块(这里注册的意思就是告诉),服务发现就以K-V的方式记录下,K一般是服务名,V就是IP:PORT。服务发现模块定时的轮询查看这些服务能不能访问的了(这就是健康检查)。客户端在调用服务A-N的时候,就跑去服务发现模块问下它们的网络位置,然后再调用它们的服务。这样的方式是不是就可以解决上面的问题了呢?客户端完全不需要记录这些服务网络位置,客户端和服务端完全解耦!
参考文章
ZooKeeper(注:ZooKeeper是著名Hadoop的一个子项目,旨在解决大规模分 布式应用场景下,服务协调同步(Coordinate Service)的问题;它可以为同在一个分布式系统中的其他服务提供:统一命名服务、配置管理、分布式锁服务、集群管理等功能)是个伟大的开源项目,它 很成熟,有相当大的社区来支持它的发展,而且在生产环境得到了广泛的使用
ZooKeeper是个 CP的,即任何时刻对ZooKeeper的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注:也就 是在极端环境下,ZooKeeper可能会丢弃一些请求,消费者程序需要重新请求才能获得结果)
ZooKeeper的核心实现算法 Zab,就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。
是一个开源的服务发现解决方案,由Netflix公司开发。(注:Eureka由两个组件组成:Eureka服务器和Eureka客户端。Eureka服务器用作 服务注册服务器。Eureka客户端是一个java客户端,用来简化与服务器的交互、作为轮询负载均衡器,并提供服务的故障切换支持。)
正常配置下,Eureka内置了心跳服务,用于淘汰一些“濒死”的服务器;如果在Eureka中注册的服务, 它的“心跳”变得迟缓时,Eureka会将其整个剔除出管理范围(这点有点像ZooKeeper的做法)。
如果Eureka服务节点在短时间里丢失了大量的心跳连接(注:可能发生了网络故障),那么这个 Eureka节点会进入”自我保护模式“,同时保留那些“心跳死亡“的服务注册信息不过期。此时,这个Eureka节点对于新的服务还能提供注册服务,对 于”死亡“的仍然保留,以防还有客户端向其发起请求。当网络故障恢复后,这个Eureka节点会退出”自我保护模式“。
扩展——CAP原则
CAP原则又称CAP定理,指的是在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。
参考文章
做服务发现的框架常用的有
consul是分布式的、高可用、横向扩展的。consul提供的一些关键特性:
[外链图片转存失败(img-6ZPZsnJ4-1567133099754)(https://www.consul.io/assets/images/consul-arch-420ce04a.png)]
我们只看数据中心1,可以看出consul的集群是由N个SERVER,加上M个CLIENT组成的。而不管是SERVER还是CLIENT,都是consul的一个节点,所有的服务都可以注册到这些节点上,正是通过这些节点实现服务注册信息的共享。除了这两个,还有一些小细节,一一简单介绍。
CLIENT
CLIENT表示consul的client模式,就是客户端模式。是consul节点的一种模式,这种模式下,所有注册到当前节点的服务会被转发到SERVER,本身是不持久化这些信息。
SERVER
SERVER表示consul的server模式,表明这个consul是个server,这种模式下,功能和CLIENT都一样,唯一不同的是,它会把所有的信息持久化的本地,这样遇到故障,信息是可以被保留的。
SERVER-LEADER
中间那个SERVER下面有LEADER的字眼,表明这个SERVER是它们的老大,它和其它SERVER不一样的一点是,它需要负责同步注册的信息给其它的SERVER,同时也要负责各个节点的健康监测。
其它信息
其它信息包括它们之间的通信方式,还有一些协议信息,算法。它们是用于保证节点之间的数据同步,实时性要求等等一系列集群问题的解决。
参考文章——高并发下接口幂等性解决方案
1、Nginx与Zuul的区别
相同点:
Zuul和Nginx都可以实现负载均衡、反向代理(隐藏真实ip地址),过滤请求,实现网关的效果
不同点:
Nginx--c语言开发
Zuul--java语言开发
Zuul负载均衡实现:采用ribbon+eureka实现本地负载均衡
Nginx负载均衡实现:采用服务器实现负载均衡
Nginx相比zuul功能会更加强大,因为Nginx整合一些脚本语言(Nginx+lua)
Nginx适合于服务器端负载均衡
Zuul适合微服务中实现网关
Ribbon客户端负载
Dubbo服务调用原理
越往后性能越低的原因?
*** limit [offset,] rows。越往后offset越大,即偏移量越大。
解决方案
select * from mytbl where id >= ( select id from mytbl order by id limit 100000,1 ) limit 10 注:假设id是主键索引,那么里层走的是索引,外层也是走的索引,所以性能大大提高
即将offset转换成一个使用了索引的条件