JAVA常考点4css
二、Java中Integer型和int型的差异 3mysql
九、servlet里面有哪些方法?说一说get和post方法的差异 5
十一、具体解释synchronized与Lock的差异与使用 6
十二、悲观锁。乐观锁,行锁。表锁,页锁,共享锁。排他锁 17
弄清怎么个逻辑达到元素不反复的,源代码先上
HashSet 类中的add()方法:
public boolean add(E e) {
return map.put(e, PRESENT)==null;
}
类中map和PARENT的定义:
private transient HashMap<E,Object> map;
// Dummy value to associate with an Object in the backing Map用来匹配Map中后面的对象的一个虚拟值
private static final Object PRESENT = new Object();
put()方法:
public V put(K key, V value) {
if (key == null)
return putForNullKey(value);
int hash = hash(key.hashCode());
int i = indexFor(hash, table.length);
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
return oldValue;
}
}
modCount++;
addEntry(hash, key, value, i);
return null;
}
可以看到for循环中,遍历table中的元素,
假设hash码值不一样样。说明是一个新元素,存。
假设没有元素和传入对象(也就是add的元素)的hash值相等,那么就以为这个元素在table中不存在,将其加入进table;
假设hash码值一样,且equles推断相等,说明元素已经存在,不存;
假设hash码值一样,且equles推断不相等。说明元素不存在,存;
假设有元素和传入对象的hash值相等,那么,继续进行equles()推断,假设仍然相等,那么就以为传入元素已经存在,再也不加入。结束,不然仍然加入;
可见hashcode()和equles()在此显得很是关键了,如下就来解读一下hashcode和equles:
首先要明白:仅仅经过hash码值来推断两个对象时否一样合适吗?答案是不合适的,因为有可能两个不一样的对象的hash码值一样;
什么是hash码值?
在java中存在一种hash表结构,它经过一个算法,计算出的结果就是hash码值;这个算法叫hash算法。
hash算法是怎么计算的呢?
是经过对象中的成员来计算出来的结果;
假设成员变量是基本数据类型的值。 那么用这个值 直接參与计算;
假设成员变量是引用数据类型的值,那么获取到这个成员变量的哈希码值后。再參数计算
如:新建一个Person对象。重写hashCode方法
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + age;
result = prime * result + ((name == null) ?
0 : name.hashCode());
return result;
}
可以看出,Person对象内两个參数name,age。hash码值是这二者计算后的记过,那么全然有可能两个对象name。age都不一样,hash码值一样;
如下看下equles()方法:
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Person other = (Person) obj;
if (age != other.age)
return false;
if (name == null) {
if (other.name != null)
return false;
} else if (!name.equals(other.name))
return false;
return true;
}
equles方法内部是分别对name,age进行推断,是否相等。
综合上述,在向hashSet中add()元素时。推断元素是否存在的根据,不只仅是hash码值就可以肯定的,同一时候还要结合equles方法。
a.Java 中的数据类型分为基本数据类型和引用数据类型。int是基本数据类型,直接存放值。而而Integer是对象。用一个引用指向这个对象。Ingeter是int的包装类。int的初值为0。Ingeter的初值为null。
b.初始化
int i =1。
Integer i= new Integer(1)。
有了本身主动装箱和拆箱。使得对Integer类也可以使用:
Integer i= 100;
实际上上面这个代码调用了:
Integer i = Integer.valueOf(100);
c.Integer是int的封装类,int和Integer都可以表示某一个数值,int和Integer不可以互用,因为他们两种不一样的数据类型。
接口不只可以继承接口,而且一个接口可以继承多个接口,接口是特殊的抽象类。
抽象类不可以继承接口。但可以实现接口。抽象类可以继承实体类,但是不能继承接口。
长处:建立索引主要可以大大提升系统性能,主要优点有如下5点:
经过建立惟一性索引,可以保证数据库表中每一行数据的惟一性。
可以大大加快 数据的检索速度,这也是建立索引的最基本的缘由。
可以加速表和表之间的链接,特别是在实现数据的參考完整性方面特别有意义。
在使用分组和排序 子句进行数据检索时,一样可以显著下降查询中分组和排序的时间。
经过使用索引。可以在查询的过程当中。使用优化隐藏器,提升系统的性能。
缺点:
建立索引和维护索引要耗费时间。这样的时间随着数据 量的添加而添加。
索引需要占物理空间,除了数据表占数据空间以外,每一个索引还要占必定的物理空间,假设要创建聚簇索引,那么需要的空间就会更大。
当对表中的数据进行添加、删除和改动的时候,索引也要动态的维护。这样就下降了数据的维护速度。
索引主要有两个特征:惟一性索引和复合索引。
ALTER TABLE 表名 MODIFY COLUMN 字段名 字段类型定义;(注意不是update)
HAVING 就像WHERE条件同样。按指定要求来取数据集。
仅仅只是WHERE通常数据查询来指定条件,HAVING是用在GROUP BY 分组来指定条件。
HAVING 子句运作起来很是象 WHERE 子句。 仅仅用于对那些知足 HAVING 子句里面给出的条件的组进行计算。
事实上,WHERE 在分组和汇集以前过滤掉咱们不需要的输入行, 而 HAVING 在 GROUP 以后那些不需要的组. 所以,WHERE 没法使用一个汇集函数的结果. 而另外一方面,咱们也没有理由写一个不涉及汇集函数的 HAVING. 假设你的条件不包括汇集。那么你也可以把它写在 WHERE 里面。 这样就可以避免对那些你准备抛弃的行进行的汇集运算.
归并排序:简单来讲就是先将数组不断细分红最小的单位,而后每一个单位分别排序,排序完成后合并,反复以上过程最后就可以获得排序结果。
复杂度:O(nlogn) 妥当
高速排序:简单来讲就是先选定一个基准元素,而后以该基准元素划分数组,再在被划分的部分反复以上过程,最后可以获得排序结果。
复杂度:O(nlogn) 不稳定
二者都是用分治法的思想。只是最后归并排序的合并操做比高速排序的要繁琐。
final修饰类,类不能被继承
final修饰方法。方法不能被覆写
final修饰的变量初始化后则不能被改动。
init() 、destroy() 、service()等。
在servlet开发中,以doGet()和doPost()分别处理get和post方法。另外另外一个doService(), 它是一个调度方法,当一个请求发生时,首先运行doService(),不管是get仍是post。在HttpServlet这个基类中实现了一个角度。首先推断是请求时get仍是post,假设是get就调用doGet(), 假设是post就调用doPost()。
你也可以直接过载doService()方法,这样你可以不管是get仍是post。都会运行这种方法。
get和post方法的差异:
a)顺序存储结构:
长处:
随机读取(时间复杂度为O(1))
无需为表示表中元素之间的逻辑关系而添加额外的存储空间
缺点:
插入、删除操做需要移动大量元素。效率低(时间复杂度为O(n))。
表的长度难以肯定
b)链式存储结构.
长处:
插入、删除不需要移动数据。效率高(时间复杂度为O(1));
缺点:
存取时需要遍历,效率低(时间复杂度为O(n));
顺序存储结构通常用于:频繁查找,很是少插入、删除;而链式存储结构通常用于频繁插入、删除;
引言:
昨天在学习别人分享的面试经验时,看到Lock的使用。
想起本身在上次面试也遇到了synchronized与Lock的差异与使用。
因而。我整理了二者的差异和使用状况,同一时候,对synchronized的使用过程一些常见问题的总结。最后是參照源代码和说明文档。对Lock的使用写了几个简单的Demo。
请你们批评指正。
技术点:
(1)线程与进程:
在開始以前先把进程与线程进行区分一下。一个程序最少需要一个进程,而一个进程最少需要一个线程。
关系是线程–>进程–>程序的大体组成结构。因此线程是程序运行流的最小单位。而进程是系统进行资源分配和调度的一个独立单位。如下咱们所有讨论的都是创建在线程基础之上。
(2)Thread的几个重要方法:
咱们先了解一下Thread的几个重要方法。
a、start()方法,调用该方法開始运行该线程;b、stop()方法,调用该方法强制结束该线程运行。c、join方法,调用该方法等待该线程结束。d、sleep()方法,调用该方法该线程进入等待。
e、run()方法,调用该方法直接运行线程的run()方法,但是线程调用start()方法时也会运行run()方法。差异就是一个是由线程调度运行run()方法,一个是直接调用了线程中的run()方法!
!
看到这里,可能有些人就会问啦。那wait()和notify()呢?要注意。事实上wait()与notify()方法是Object的方法。不是Thread的方法。!同一时候,wait()与notify()会配合使用,分别表示线程挂起和线程恢复。
这里另外一个非常常见的问题,顺带提一下:wait()与sleep()的差异。简单来讲wait()会释放对象锁而sleep()不会释放对象锁。
这些问题有很是多的资料,再也不赘述。
(3)线程状态:
线程总共同拥有5大状态,经过上面第二个知识点的介绍。理解起来就简单了。
新建状态:新建线程对象。并无调用start()方法以前
就绪状态:调用start()方法以后线程就进入就绪状态。但是并不是说仅仅要调用start()方法线程就当即变为当前线程,在变为当前线程以前都是为就绪状态。
值得一提的是,线程在睡眠和挂起中恢复的时候也会进入就绪状态哦。
运行状态:线程被设置为当前线程,開始运行run()方法。就是线程进入运行状态
堵塞状态:线程被暂停,比方说调用sleep()方法后线程就进入堵塞状态
死亡状态:线程运行结束
(4)锁类型
可重入锁:在运行对象中所有同步方法不用再次得到锁
可中断锁:在等待获取锁过程当中可中断
公平锁: 按等待获取锁的线程的等待时间进行获取,等待时间长的具备优先获取锁权利
读写锁:对资源读取和写入的时候拆分为2部分处理。读的时候可以多线程一块儿读,写的时候必须同步地写
synchronized与Lock的差异
(1))我把二者的差异分类到了一个表中,方便你们对照:
也许,看到这里还对LOCK所知甚少,那么接下来,咱们进入LOCK的深刻学习。
Lock具体介绍与Demo
如下是Lock接口的源代码。笔者修剪以后的结果:
public interface Lock {
/**
* Acquires the lock.
*/
void lock();
/**
* Acquires the lock unless the current thread is
* {@linkplain Thread#interrupt interrupted}.
*/
void lockInterruptibly() throws InterruptedException;
/**
* Acquires the lock only if it is free at the time of invocation.
*/
boolean tryLock();
/**
* Acquires the lock if it is free within the given waiting time and the
* current thread has not been {@linkplain Thread#interrupt interrupted}.
*/
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
/**
* Releases the lock.
*/
void unlock();
}
从Lock接口中咱们可以看到主要有个方法。这些方法的功能从凝视中可以看出:
lock():获取锁,假设锁被暂用则一直等待
unlock():释放锁
tryLock(): 注意返回类型是boolean。假设获取锁的时候锁被占用就返回false,不然返回true
tryLock(long time, TimeUnit unit):比起tryLock()就是给了一个时间期限,保证等待參数时间
lockInterruptibly():用该锁的得到方式,假设线程在获取锁的阶段进入了等待,那么可以中断此线程,先去作别的事
经过 以上的解释,大体可以解释在上个部分中“锁类型(lockInterruptibly())”,“锁状态(tryLock())”等问题。还有就是前面子所获取的过程我所写的“大体就是可以尝试得到锁,线程可以不会一直等待”用了“可以”的缘由。
如下是Lock通常使用的样例,注意ReentrantLock是Lock接口的实现。
lock():
package com.brickworkers;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class LockTest {
private Lock lock = new ReentrantLock();
//需要參与同步的方法
private void method(Thread thread){
lock.lock();
try {
System.out.println("线程名"+thread.getName() + "得到了锁");
}catch(Exception e){
e.printStackTrace();
} finally {
System.out.println("线程名"+thread.getName() + "释放了锁");
lock.unlock();
}
}
public static void main(String[] args) {
LockTest lockTest = new LockTest();
//线程1
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
lockTest.method(Thread.currentThread());
}
}, "t1");
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
lockTest.method(Thread.currentThread());
}
}, "t2");
。t1.start();
。t2.start();
}
}
//运行状况:线程名t1得到了锁
// 线程名t1释放了锁
// 线程名t2得到了锁
// 线程名t2释放了锁
tryLock():
package com.brickworkers;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class LockTest {
private Lock lock = new ReentrantLock();
//需要參与同步的方法
private void method(Thread thread){
/* lock.lock();
try {
System.out.println("线程名"+thread.getName() + "得到了锁");
}catch(Exception e){
e.printStackTrace();
} finally {
System.out.println("线程名"+thread.getName() + "释放了锁");
lock.unlock();
}*/
if(lock.tryLock()){
try {
System.out.println("线程名"+thread.getName() + "得到了锁");
}catch(Exception e){
e.printStackTrace();
} finally {
System.out.println("线程名"+thread.getName() + "释放了锁");
lock.unlock();
}
}else{
System.out.println("我是"+Thread.currentThread().getName()+"有人占着锁,我就不要啦");
}
}
public static void main(String[] args) {
LockTest lockTest = new LockTest();
//线程1
Thread t1 = new Thread(new Runnable() {
@Override
public void run() {
lockTest.method(Thread.currentThread());
}
}, "t1");
Thread t2 = new Thread(new Runnable() {
@Override
public void run() {
lockTest.method(Thread.currentThread());
}
}, "t2");
。t1.start();
。t2.start();
}
}
//运行结果: 线程名t2得到了锁
// 我是t1有人占着锁,我就不要啦
// 线程名t2释放了锁
看到这里相信你们也都会使用怎样使用Lock了吧。关于tryLock(long time, TimeUnit unit)和lockInterruptibly()再也不赘述。前者主要存在一个等待时间,在測试代码中写入一个等待时间。后者主要是等待中断,会抛出一个中断异常,常用度不高,喜欢探究可以本身深刻研究。
前面比較重提到“公平锁”。在这里可以提一下ReentrantLock对于平衡锁的定义。在源代码中有这么两段:
/**
* Sync object for non-fair locks
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
/**
* Performs lock. Try immediate barge, backing up to normal
* acquire on failure.
*/
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}
/**
* Sync object for fair locks
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -3000897897090466540L;
final void lock() {
acquire(1);
}
/**
* Fair version of tryAcquire. Don't grant access unless
* recursive call or no waiters or is first.
*/
protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() &&
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
}
从以上源代码可以看出在Lock中可以本身控制锁是否公平,而且,默认的是非公平锁,如下是ReentrantLock的构造函数:
public ReentrantLock() {
sync = new NonfairSync();//默认非公平锁
}
尾记录:
笔者水平通常,只是此博客在引言中的目的已所有达到。这仅仅是笔者在学习过程当中的总结与归纳,如存在不对的,欢迎你们批评指出。
延伸学习:对于LOCK底层的实现。你们可以參考:
点击Lock底层介绍博客
两种同步方式性能測试,你们可以參考:
点击查看两种同步方式性能測试博客
博主18年3月新增:
回来看本身博客。
发现东西阐述的不够完整。这里在作补充,因为这篇博客訪问较大,因此为了避免误导你们,尽可能介绍给你们正确的表述:
(1)两种锁的底层实现方式:
synchronized:咱们知道java是用字节码指令来控制程序(这里不包括热点代码编译成机器码)。在字节指令中,存在有synchronized所包括的代码块。那么会造成2段流程的运行。
咱们点击查看SyncDemo.java的源代码SyncDemo.class,可以看到例如如下:
如上就是这段代码段字节码指令。没你想的那么难吧。言归正传。咱们可以清晰段看到。事实上synchronized映射成字节码指令就是添加来两个指令:monitorenter和monitorexit。
当一条线程进行运行的遇到monitorenter指令的时候,它会去尝试得到锁。假设得到锁那么锁计数+1(为何会加一呢,因为它是一个可重入锁,因此需要用这个锁计数推断锁的状况),假设没有得到锁,那么堵塞。当它遇到monitorexit的时候,锁计数器-1,当计数器为0。那么就释放锁。
那么有的朋友看到这里就疑惑了,那图上有2个monitorexit呀?当即回答这个问题:上面我曾经写的文章也有表述过,synchronized锁释放有两种机制,一种就是运行完释放;第二种就是发送异常。虚拟机释放。图中第二个monitorexit就是发生异常时运行的流程,这就是我开头说的“会有2个流程存在“。
而且,从图中咱们也可以看到在第13行。有一个goto指令,也就是说假设正常运行结束会跳转到19行运行。
这下,你对synchronized是否是了解的很是清晰了呢。接下来咱们再聊一聊Lock。
Lock:Lock实现和synchronized不同。后者是一种悲观锁,它胆子很是小,它很是怕有人和它抢吃的,因此它每次吃东西前都把本身关起来。
而Lock呢底层事实上是CAS乐观锁的体现,它无所谓。别人抢了它吃的,它又一次去拿吃的就好啦,因此它很是乐观。具体底层怎么实现,博主不在细述。有机会的话。我会对concurrent包如下的机制好好和你们说说,假设面试问起。你就说底层主要靠volatile和CAS操做实现的。
现在,才是我真正想在这篇博文后面加的,我要说的是:尽量去使用synchronized而不要去使用LOCK
什么概念呢?我和你们打个比方:你叫jdk,你生了一个孩子叫synchronized,后来呢,你领养了一个孩子叫LOCK。起初。LOCK刚来到新家的时候,它很是乖,很是懂事。各个方面都表现的比synchronized好。
你很是开心,但是你心里深处又有一点淡淡的忧伤。你不但愿你本身亲生的孩子竟然还不如一个领养的孩子乖巧。这个时候,你对亲生的孩子教育更加深入了。你想证实。你的亲生孩子synchronized并不会比领养的孩子LOCK差。(博主仅仅是打个比方)
那怎样教育呢?
在jdk1.6~jdk1.7的时候,也就是synchronized1六、7岁的时候。你做为爸爸,你给他优化了,具体优化在哪里呢:
(1)线程自旋和适应性自旋
咱们知道。java’线程事实上是映射在内核之上的。线程的挂起和恢复会极大的影响开销。
而且jdk官方人员发现,很是多线程在等待锁的时候。在很是短的一段时间就得到了锁,因此它们在线程等待的时候,并不需要把线程挂起,而是让他无目的的循环。通常设置10次。这样就避免了线程切换的开销,极大的提高了性能。
而适应性自旋,是赋予了自旋一种学习能力。它并不固定自旋10次一下。
他可以根据它前面线程的自旋状况,从而调整它的自旋,甚至是不通过自旋而直接挂起。
(2)锁消除
什么叫锁消除呢?就是把没必要要的同步在编译阶段进行移除。
那么有的小伙伴又迷糊了,我本身写的代码我会不知道这里要不要加锁?我加了锁就是表示这边会有同步呀?
并不是这样。这里所说的锁消除并不必定指代是你写的代码的锁消除,我打一个比方:
在jdk1.5曾经。咱们的String字符串拼接操做事实上底层是StringBuffer来实现的(这个你们可以用我前面介绍的方法。写一个简单的demo,而后查看class文件里的字节码指令就清晰了),而在jdk1.5以后,那么是用StringBuilder来拼接的。
咱们考虑前面的状况,比方例如如下代码:
String str1="qwe";
String str2="asd";
String str3=str1+str2;
底层实现会变成这样:
StringBuffer sb = new StringBuffer();
sb.append("qwe");
sb.append("asd");
咱们知道。StringBuffer是一个线程安全的类。也就是说两个append方法都会同步。经过指针逃逸分析(就是变量不会外泄),咱们发现在这段代码并不存在线程安全问题。这个时候就会把这个同步锁消除。
(3)锁粗化
在用synchronized的时候,咱们都讲究为了不大开销,尽可能同步代码块要小。那么为何还要加粗呢?
咱们继续以上面的字符串拼接为例,咱们知道在这一段代码中,每一个append都需要同步一次。那么我可以把锁粗化到第一个append和最后一个append(这里不要去纠结前面的锁消除。我仅仅是打个比方)
(4)轻量级锁
(5)偏向锁
关于最后这两种,我但愿留个有缘的读者本身去查找,我不但愿我把一件事情描写叙述的那么具体,本身动手获得才是你本身的,博主可以告诉你的是。最后两种并不难。
。加油吧,各位。
悲观锁:
顾名思义,很是悲观,就是每次拿数据的时候都以为别的线程会改动数据,因此在每次拿的时候都会给数据上锁。上锁以后,当别的线程想要拿数据时。就会堵塞。直到给数据上锁的线程将事务提交或者回滚。传统的关系型数据库里就用到了很是多这样的锁机制,比方行锁。表锁。共享锁,排他锁等,都是在作操做以前先上锁。
行锁:
如下演示行锁,打开两个mysql命令行界面。两个线程分别运行例如如下操做:(左边先运行)
左边的线程,在事务中经过select for update语句给sid = 1的数据行上了锁。右边的线程此时可以使用select语句读取数据,但是假设也使用select for update语句,就会堵塞,使用update。add,delete也会堵塞。
当左边的线程将事务提交(或者回滚),右边的线程就会获取锁,线程再也不堵塞:
此时,右边的线程获取锁。左边的线程假设运行类似操做,也会被堵塞:
表锁:
上述样例中,假设使用例如如下语句就是使用的表锁:
select * from student for update;
页锁:
行锁锁指定行。表锁锁整张表。页锁是折中实现。即一次锁定相邻的一组记录。
共享锁:
共享锁又称为读锁,一个线程给数据加上共享锁后,其它线程仅仅能读数据,不能改动。
排他锁:
排他锁又称为写锁。和共享锁的差异在于。其它线程既不能读也不能改动。
乐观锁:
乐观锁事实上不会上锁。顾名思义。很是乐观,它默认别的线程不会改动数据,因此不会上锁。
仅仅是在更新前去推断别的线程在此期间有没有改动数据。假设改动了。会交给业务层去处理。
常用的实现方式是使用版本号戳,好比在一张表中加入一个整型字段version,每更新version++,比方某个时刻version=1,线程A读取了此version=1,线程B也读取了此version=1,当线程A更新数据以前,推断version仍然为1。更新成功。version++变为2。但是当线程B再提交更新时,发现version变为2了,与以前读的version=1不一致,就知道有别的线程更新了数据,这个时候就会进行业务逻辑的处理。
一般状况下,写操做较少时,使用乐观锁,写操做较多时,使用悲观锁。