用友一面面经

最新推荐文章于 2024-04-05 09:34:23 发布

IT界的徐小渣

最新推荐文章于 2024-04-05 09:34:23 发布

阅读量307

点赞数

文章标签： java

本文链接：https://blog.csdn.net/qq_43505820/article/details/120377256

版权

1.介绍一下io流，知道多少说多少。
**在这里插入图片描述

答：
https://www.cnblogs.com/zhaosq/p/9889774.html

FileInputStream用到了什么设计模式？BufferInputStream呢？
FileInputStream用到了适配器模式；BufferInputStream用到了装饰器模式

//1、获得子节输入流
    FileInputStream fileInputStream=new FileInputStream(file);
    //2、构造转换流(是继承Reader的)
    InputStreamReader inputStreamReader=new InputStreamReader(fileInputStream);
    //3、 构造缓冲字符流
    BufferedReader bufferedReader=new BufferedReader(inputStreamReader);
 
    //备注1、2两步骤体现出了适配器模式
    //2步骤体现了InputStreamReader类具有将子节输入流转换为字符输入流的功能
    //2、3两步骤体现了装饰模式(wrapper包装模式)

2.介绍一下进程相关的，共有几种状态？介绍一下你了解的锁？多读少写用什么锁，少写多读呢？lock与synchronized的区别？

在这里插入图片描述

(几种常见的线程锁)
https://www.jianshu.com/p/d2689161bf4e

线程的同步是为了防止多个线程访问一个数据对象时，对数据造成的破坏。

锁：
①悲观锁：适用于多写，竞争激烈的场景。
分为：共享锁（读锁 s锁）和排他锁（写锁 x锁）
②乐观锁：少锁，写少竞争不激烈（使用数据版本version++ 或者使用时间戳）
CAS（乐观锁）缺点：不能保证代码块的原子性，只能保证单个变量的原子性。
synchronized （悲观锁）：修饰类，代码块，方法:让没有得到锁资源的线程进入blocked状态，获取锁后回复为running状态，涉及操作系统用户模式和内核模式的转换，代价较高。
公平性锁与非公平锁：
ReentrantLock ：非公平的，传入参数true即为公平锁。优劣：在CPU线程状态切换的空挡期较长的情况下，非公平锁性能高于公平锁性能。首先，在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。而且，非公平锁能更充分的利用cpu的时间片，尽量的减少cpu空闲的状态时间。
自旋锁：当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。
互斥锁mutex:
在访问共享资源之前对进行加锁操作，在访问完成之后进行解锁操作。
加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。
如果解锁时有一个以上的线程阻塞，那么所有该锁上的线程都被编程就绪状态，
第一个变为就绪状态的线程又执行加锁操作，那么其他的线程又会进入等待。
在这种方式下，只有一个线程能够访问被互斥锁保护的资源。
读写锁 rwlock（ReadWriteLock）：
读写锁非常适合对数据结构读的次数远远大于写的情况。
当处于读模式的读写锁接收到一个试图对其进行写模式加锁操作时，便会阻塞后面对其进行读模式加锁操作的线程。这样等到已经加读模式的锁解锁后，写进程能够访问此锁保护的资源。

ReadWriteLock提供了readLock和writeLock两种锁的操作机制，一个是读锁，一个是写锁，而它的实现类就是ReentranReadWriteLock。
RRW 允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问。

3.JVM：什么情况会出现内存泄漏,如何避免? 创建对象后生成的对象存放的具体位置（堆），如何进行垃圾回收（复制算法，标记清除，标记整理）？了解多少垃圾收集器？cms收集器和G1收集器有什么区别？

我们都知道Java中对未被引用的对象进行垃圾回收，如果还有引用的话，那就让它多活一会儿。但是假设我们考虑这样一种情况，在内存中有这么两个对象，它们一个生存周期远大于另一个生存周期，而且生存周期大的对象有指向生存周期小的对象的引用，而且生存周期小的对象不再有指向其他对象的引用，那好，既然大的有指向小的引用，那垃圾回收器对小的也无可奈何。

1.对象内存过大

保存了多个好用内存过大的对象，造成内存超出限制。

2.资源释放

程序代码的问题，长期保持某些资源，如Context，Cursor，IO流的引用，资源得不到释放造成内存泄露。

3.static关键字的使用

static 是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例，就可能会造成内存的泄露。

针对static的解决方案：

应该尽量避免static成员变量引用资源耗费过多的实例，比如Context.

Context尽量使用ApplicationContext的生命周期比较长，引用它不会出现内存泄露。

使用WeakReference代替强引用。比如可以使用WeakReference mContext;

4.线程导致内存溢出

线程产生内存泄露的主要原因在于线程生命周期的不可控。如当我们切换横竖屏的时候，一般会重新创建Activity，老的Activity应该被销毁。但是此时我们在子线程中正在进行耗时的操作，老的Activity不会被销毁，这个时候就会出现内存泄露。