面试题(六)

太过爱你忘了你带给我的痛 2022-08-29 00:18 205阅读 0赞

**23.多线程的实现方式**

1）继承Thread类

2) 实现Runnable接口

3) 实现 Callable 接口。 相较于实现 Runnable 接口的方式，方法可以有返回值，并且可以抛出异常,执行 Callable 方式，需要 FutureTask 实现类的支持，用于接收运算结果。  FutureTask 是  Future 接口的实现类

**24.线程的状态转换**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70][]

**25. 如何停止一个线程**

1.  线程自然终止：自然执行完或抛出未处理异常
2.  使用stop方法强行终止线程，但线程中的stop(), resume(),suspend()已不建议使用，stop()会导致线程不会正确释放资源，suspend()容易导致死锁。因为java线程是协作式，而非抢占式.
3.  使用interrupt方法终止线程. 调用一个线程的interrupt() 方法中断一个线程，并不是强行关闭这个线程，只是跟这个线程打个招呼，将线程的中断标志位置为true，线程是否中断，由线程本身决定。而isInterrupted() 判定当前线程是否处于中断状态。static方法interrupted() 判定当前线程是否处于中断状态，同时中断标志位改为false。方法里如果抛出InterruptedException，线程的中断标志位会被复位成false，如果确实是需要中断线程，要求我们自己在catch语句块里再次调用interrupt()。

**   参考: https://blog.csdn.net/anhuidelinger/article/details/11746365**

**26.什么是线程安全**

**    **当多个线程访问某一个类（对象或方法）时，对象对应的公共数据区始终都能表现正确，那么这个类（对象或方法）就是线程安全的

**27.如何保证线程安全**

线程安全在三个方面体现1.原子性：提供互斥访问，同一时刻只能有一个线程对数据进行操作，（atomic,synchronized）；2.可见性：一个线程对主内存的修改可以及时地被其他线程看到，（synchronized,volatile）；3.有序性：一个线程观察其他线程中的指令执行顺序，由于指令重排序，该观察结果一般杂乱无序，（happens-before原则）.

那么保证线程的安全性可以从以下三个方面着手: 1. 对非安全的代码进行加锁控制；2. 使用线程安全的类；3. 多线程并发情况下，线程共享的变量改为方法级的局部变量

**28.synchronized如何使用**

1). 无论synchronized关键字加在方法上还是对象上，如果它作用的对象是非静态的，则它取得的锁是对象(对象锁)；如果synchronized作用的对象是一个静态方法或一个类，则它取得的锁是对类，该类所有的对象同一把锁(类锁)。   
2). 每个对象只有一个锁（lock）与之相关联，谁拿到这个锁谁就可以运行它所控制的那段代码。   
    3) . 实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制

**29.synchronized和Lock的区别**

synchronized原始采用的是CPU悲观锁机制，即线程获得的是独占锁。独占锁意味着其他线程只能依靠阻塞来等待线程释放锁。而在CPU转换线程阻塞时会引起线程上下文切换，当有很多线程竞争锁的时候，会引起CPU频繁的上下文切换导致效率很低。

而Lock用的是乐观锁方式。所谓乐观锁就是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。乐观锁实现的机制就是CAS操作（Compare and Swap）。研究java.util.concurrent.ReentrantLock的源代码，会发现其中比较重要的获得锁的一个方法是compareAndSetState。这里其实就是调用的CPU提供的特殊指令。现代的CPU提供了指令，可以自动更新共享数据，而且能够检测到其他线程的干扰，而 compareAndSet() 就用这些代替了锁定。这个算法称作非阻塞算法，意思是一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法.

synchronized原语和ReentrantLock在一般情况下没有什么区别，但是在非常复杂的同步应用中，请考虑使用ReentrantLock，特别是遇到下面需求的时候。

1.  某个线程在等待一个锁的控制权的这段时间需要中断  
    2.需要分开处理一些wait-notify，ReentrantLock里面的Condition应用，能够控制notify哪个线程  
    另外:  synchronized是托管给JVM执行的，而lock是java写的控制锁的代码. 在Java1.5中，synchronize是性能低效的。因为这是一个重量级操作，需要调用操作接口，导致有可能加锁消耗的系统时间比加锁以外的操作还多。相比之下使用Java提供的Lock对象，性能更高一些。但是到了Java1.6，发生了变化。synchronized在语义上很清晰，可以进行很多优化，有适应自旋，锁消除，锁粗化，轻量级锁，偏向锁等等。导致在Java1.6上synchronize的性能并不比Lock差。官方也表示，他们也更支持synchronize，在未来的版本中还有优化余地.

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 1][]

**30.多线程如何进行等待通知/信息交互**

void notify() 唤醒在此对象监视器上等待的单个线程。  
void notifyAll() 唤醒在此对象监视器上等待的所有线程。  
void wait() 导致当前的线程等待，直到其他线程调用此对象的notify()方法或notifyAll()方法。  
void wait(long timeout) 导致当前的线程等待，直到其他线程调用此对象的notify()方法或notifyAll()方法，或者超过指定的时间量。  
void wait(long timeout, int nanos) 导致当前的线程等待，直到其他线程调用此对象的notify()方法或notifyAll()方法，或者其他某个线程中断当前线程，或者已超过某个实际时间量。

**31.sleep和wait的区别(考察的方向是是否会释放锁)**

**   **sleep和wait的区别在于这两个方法来自不同的类分别是Thread和Object，sleep方法没有释放锁，而wait方法释放了锁，使得其他线程可以使用同步控制块或者方法。wait只能在同步控制方法或者同步控制块里面使用，而sleep可以在任何地方使用(使用范围)。

**32.多线程与死锁**

死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，它们都将无法推进下去。  
产生死锁的原因：  
一.因为系统资源不足。  
二.进程运行推进的顺序不合适。  
三.资源分配不当。

**33.如何才能产生死锁**

产生死锁的四个必要条件：  
一.互斥条件：所谓互斥就是进程在某一时间内独占资源。  
二.请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。  
三.不剥夺条件:进程已获得资源，在末使用完之前，不能强行剥夺。  
四.循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

**34.死锁的预防**

打破产生死锁的四个必要条件中的一个或几个，保证系统不会进入死锁状态。  
一.打破互斥条件。即允许进程同时访问某些资源。但是，有的资源是不允许被同时访问的，像打印机等等，这是由资源本身的属性所决定的。所以，这种办法并无实用价值。  
二.打破不可抢占条件。即允许进程强行从占有者那里夺取某些资源。就是说，当一个进程已占有了某些资源，它又申请新的资源，但不能立即被满足时，它必须释放所占有的全部资源，以后再重新申请。它所释放的资源可以分配给其它进程。这就相当于该进程占有的资源被隐蔽地强占了。这种预防死锁的方法实现起来困难，会降低系统性能。  
三.打破占有且申请条件。可以实行资源预先分配策略。即进程在运行前一次性地向系统申请它所需要的全部资源。如果某个进程所需的全部资源得不到满足，则不分配任何资源，此进程暂不运行。只有当系统能够满足当前进程的全部资源需求时，才一次性地将所申请的资源全部分配给该进程。由于运行的进程已占有了它所需的全部资源，所以不会发生占有资源又申请资源的现象，因此不会发生死锁。  
四.打破循环等待条件，实行资源有序分配策略。采用这种策略，即把资源事先分类编号，按号分配，使进程在申请，占用资源时不会形成环路。所有进程对资源的请求必须严格按资源序号递增的顺序提出。进程占用了小号资源，才能申请大号资源，就不会产生环路，从而预防了死锁。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70]: /images/20220829/68b2bbdc349f47ad8ea06e6138a16336.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poYW5neWluZ2NoZW5ncWk_size_16_color_FFFFFF_t_70 1]: /images/20220829/8404a654ea9b458899a0f5d86b9ed348.png