美团下面试

单例模式中的双锁机制，分别起到了什么作用

在单例模式的双重检查锁定（DCL，Double Checked Locking）机制中，涉及到两重 “锁” 相关的操作，各自有着重要作用。

首先是外层的同步锁，也就是synchronized关键字修饰的代码块部分。它的主要作用是控制在多线程环境下，同一时刻只有一个线程能够进入到创建单例对象实例的关键代码区域。当多个线程同时调用getInstance方法尝试获取单例对象时，这个锁能够避免多个线程同时去创建实例，防止出现创建出多个实例的情况，保证了在并发场景下实例创建的唯一性。例如，线程 A 和线程 B 同时执行到获取单例对象的方法处，线程 A 获取到外层的同步锁后进入代码块，此时线程 B 就只能等待线程 A 释放锁后才有机会进入，从而避免了它们同时去执行创建实例的操作。

而内层的判空检查，也就是在同步块内再次进行的if (instance == null)判断。它的作用在于，虽然外层已经通过同步锁控制了同时只能有一个线程进入创建实例的代码块，但有可能在这个线程进入同步块前，已经有别的线程经过了外层判空检查且进入同步块创建好了实例。所以内层判空检查就是为了确保当线程进入到这个同步块内时，再次核实单例对象是否真的还没被创建，如果已经创建了就直接返回已有的实例，避免重复创建，进一步保证了单例对象创建的正确性和唯一性，优化了性能，避免了不必要的实例创建操作，提升了多线程环境下获取单例对象的效率。

双重校验锁为什么要两次判空，DCL 为什么要两次判断 null 呢？为什么使用 volatile？

两次判空的原因

第一次判空（外层判空）：其目的主要是为了避免不必要的同步开销。在多线程环境下，如果单例对象已经被创建好了，后续再有线程来获取单例对象时，其实是不需要进入同步块的，因为进入同步块需要获取锁，而获取锁这个操作是有一定性能成本的。通过第一次判空，当单例对象已经存在时，线程可以直接返回这个已有的实例，无需再进入同步代码块去执行创建实例等操作，提高了获取单例对象的效率，尤其是在高并发场景下，大量线程获取单例对象时，能减少很多不必要的等待获取锁以及执行同步块内代码的时间。
第二次判空（内层判空）：尽管外层已经通过同步锁控制了同一时刻只有一个线程能进入创建实例的代码块，但存在一种情况，就是在当前线程到达外层判空处，发现实例还没创建，正准备进入同步块时，可能已经有其他线程抢先进入同步块并且创建好了实例。所以在内层再次进行判空检查，就是为了确保进入同步块的这个线程在真正执行创建实例操作前，再核实一下实例是否真的还没被创建，如果已经被创建了，那就直接返回这个已有的实例，避免重复创建，进一步保证了单例模式中实例的唯一性，同时优化了性能，避免了不必要的实例创建步骤浪费资源。

使用 volatile 的原因

在双重校验锁的单例模式中，如果没有使用volatile关键字，可能会出现指令重排序的问题。创建单例对象的过程实际包含多个步骤，例如分配内存空间、初始化对象、将对象引用指向分配好的内存空间等。在多线程环境下，由于指令重排序，编译器或者处理器可能会对这些操作的顺序进行调整，有可能出现线程先将对象的引用赋值给单例变量（也就是让单例变量指向了还未完全初始化的内存空间），然后其他线程通过这个还未完全初始化的引用去访问对象，就会导致错误，比如获取到对象中未正确初始化的属性值等情况。而volatile关键字能够禁止指令重排序，确保对象的初始化以及引用赋值等操作按照正确的顺序执行，保证了当一个线程获取到单例对象的引用时，这个对象已经是完全初始化好的状态，避免了因指令重排序导致的数据不一致和错误访问等问题，从而保障单例模式的正确性。

不同场景下如何选择双重校验锁

双重校验锁（DCL）单例模式适用于多种场景，以下是一些不同场景下选择它的考量因素：

多线程并发且对性能有要求的场景

当应用程序处于多线程环境，多个线程可能会频繁地获取单例对象实例，并且对获取实例的性能比较敏感时，DCL 是一个不错的选择。例如在一个大型的 Web 应用服务器中，有很多线程同时处理不同用户的请求，而像数据库连接池对象往往设计为单例模式。如果采用简单的饿汉式单例，会在类加载时就创建好数据库连接池实例，可能会造成资源过早占用且浪费（如果应用启动后暂时没有大量数据库访问请求）。而使用 DCL 单例模式，一方面通过双重判空机制减少了不必要的同步开销，在单例对象已经创建好的情况下，线程能快速获取实例；另一方面，通过volatile关键字保证了在多线程并发创建实例时的正确性，既满足了多线程并发访问的需求，又兼顾了性能，避免了频繁获取锁等带来的性能损耗，使得在高并发场景下数据库连接池对象能高效地被各个线程使用。

需要延迟加载的场景

如果单例对象的创建比较耗时或者占用较多资源，并且希望在真正需要使用该单例对象时才进行创建，DCL 就很适用。比如在一个图形处理软件中，有一个用于加载和处理大型图形数据的单例对象，它在初始化时可能需要读取大量的图形文件、进行复杂的数据解析等操作，耗费较多的内存和时间。使用 DCL 单例模式，可以在第一次有线程真正需要使用这个图形处理单例对象时才去创建它，通过外层判空避免了过早创建导致的资源闲置浪费，实现了延迟加载，同时内层判空和同步机制保证了在多线程环境下只有一个这样的图形处理对象被创建出来，满足了既延迟加载又保证单例特性的需求。

对单例对象的创建过程有复杂逻辑控制的场景

有时候单例对象的创建可能需要结合一些外部条件或者复杂的逻辑判断来决定是否创建以及如何创建。例如在一个配置管理单例对象的创建中，需要先读取配置文件，根据配置文件中的某些参数来决定是否要初始化一些额外的组件并将其整合到单例对象中。DCL 模式下，外层判空可以先判断是否已经根据之前的配置情况创建好了实例，内层判空和同步块内的代码则可以保证在复杂的创建逻辑执行时，只有一个线程在进行创建操作，并且可以在同步块内加入各种复杂的条件判断和组件初始化等操作，确保单例对象按照正确的逻辑和要求被创建出来，同时又能应对多线程并发获取的情况，保障单例对象在整个应用中的唯一性和正确使用。

不过需要注意的是，虽然 DCL 有诸多优点，但它的实现相对复杂一些，需要正确理解和运用双重判空以及volatile等机制，如果使用不当可能会导致线程安全问题或者其他错误，所以在开发中要确保对其原理清晰掌握后再应用到合适的场景中。

用过的设计模式或者是安卓中遇到的设计模式

单例模式

在安卓开发中应用十分广泛。比如在整个应用的生命周期内，通常只需要一个Application类的实例，它可以作为全局的上下文来获取各种系统资源、管理应用的配置信息等，所以Application类就可以采用单例模式来实现，确保在整个安卓应用中只有这一个实例存在，各个 Activity、Service、Fragment 等组件都可以通过合适的方式获取到这个单例的Application实例来访问共享的资源或者执行相关操作。再比如，安卓中的数据库连接对象，为了避免频繁创建和销毁数据库连接带来的性能损耗以及资源浪费，一般也会设计成单例模式，方便在不同的业务逻辑模块中统一使用这个唯一的数据库连接进行数据操作。

观察者模式

安卓中的广播机制就很好地体现了观察者模式。系统或者应用会发送各种广播（如电量变化广播、网络状态变化广播等），这些广播就是主题对象，而众多注册了相应广播接收器的组件（如 Activity、Service 等）就是观察者。当广播发送时，也就是主题对象状态发生变化时，所有注册的广播接收器（观察者）都会收到通知，然后根据自己的需求进行相应的操作，比如在电量低广播收到后，某个 Activity 可以提示用户充电或者关闭一些耗电的功能等，实现了一种一对多的消息通知和响应机制，提高了组件之间的交互性和灵活性，让不同的组件可以基于系统或者应用内的各种事件变化来协同工作。

工厂模式

在安卓开发中创建不同类型的视图（View）时会用到。例如，在一个自定义的布局中，可能需要根据不同的业务需求创建不同类型的按钮、文本框等视图组件。可以创建一个视图工厂类，根据传入的参数（如视图类型、样式要求等）来创建相应的视图对象，将视图的具体创建过程和使用过程分离，方便代码的维护和扩展。如果后续需要添加新的视图类型，只需要在工厂类中添加相应的创建逻辑即可，而不需要在每个使用视图的地方都去修改代码，提高了代码的可复用性和可扩展性，并且使得视图创建的逻辑更加集中和清晰。

适配器模式

常见于列表视图（ListView、RecyclerView 等）的数据适配场景。以 RecyclerView 为例，它需要通过一个适配器（Adapter）来将数据和视图进行绑定，把数据源中的数据适配成 RecyclerView 中对应的每个 Item 视图显示出来。不同的数据结构和显示需求可以通过不同的适配器来实现，比如有展示简单文本列表的适配器，也有展示图文混排列表的适配器等。适配器在这里就起到了将原本不直接适配于 RecyclerView 显示的数据格式，转换为 RecyclerView 能够识别和展示的视图格式的作用，实现了数据与视图的解耦，方便根据不同的数据和显示要求进行灵活的列表展示，提高了列表视图使用的灵活性和可扩展性。

策略模式

在安卓应用中处理不同的图片加载策略时会用到。例如，有的图片加载场景要求快速加载，可能对图片质量要求稍低，可以采用先加载缩略图的策略；而有的场景要求图片质量高，愿意等待更长时间来加载完整清晰的图片，就可以采用高质量加载策略。可以把不同的图片加载策略封装成不同的类，每个类实现统一的图片加载接口，在具体的图片加载业务中，根据当前的应用场景（如在不同的页面或者不同的网络环境下）选择合适的图片加载策略类来进行图片加载操作，方便切换和扩展不同的加载算法，提高了图片加载功能的灵活性和可维护性。

责任链模式有哪些优势

责任链模式具有以下多方面的优势：

解耦请求发送者与接收者

在传统的代码结构中，如果一个请求需要多个对象依次处理，往往会使得请求发送者与各个处理对象之间存在紧密的耦合关系，发送者需要明确知道每个处理对象以及调用它们的顺序等。而责任链模式将这些处理对象连接成一条链，请求发送者只需要将请求发送到链的开头，无需关心后续具体是哪些对象来处理以及处理的顺序等细节，每个处理对象也不需要知道链上其他所有对象的情况，只需要关注自身是否能处理该请求以及如何处理，处理完后传递给下一个合适的对象即可。例如在一个员工请假审批系统中，普通员工发起请假申请（请求），他不需要知道是先由组长审批，再由部门经理审批，最后由总经理审批（具体的处理对象和顺序），只需要将请假申请提交到审批链的开头就行，各个审批层级（处理对象）之间也相对独立，降低了整体系统的耦合度，方便后续进行修改和扩展，比如增加新的审批层级或者调整审批顺序等都不会对请求发送者产生影响。

动态组合处理流程

责任链模式可以根据实际情况灵活地组合处理流程，链条上的处理对象可以动态地增加、删除或者调整顺序。比如在一个电商订单处理系统中，对于不同类型的订单（普通订单、团购订单、促销订单等），可能需要不同的处理流程，有的订单可能需要先进行库存检查，再进行价格核算，最后进行支付验证；而有的订单可能需要先进行优惠资格审核，再进行库存检查等。通过责任链模式，可以轻松地为不同类型的订单构建不同的处理链，将库存检查、价格核算、支付验证、优惠资格审核等这些处理对象按照不同的要求组合成不同的链条，实现了处理流程的动态配置，提高了系统对不同业务场景的适应性和灵活性，无需为每种订单类型都编写一套固定的、硬编码的处理逻辑，便于代码的维护和复用。

增强代码的可扩展性

当系统需要添加新的功能或者处理逻辑时，使用责任链模式会很方便。例如在一个文件上传系统中，原本有对文件大小检查、文件格式检查等处理环节，后续如果需要增加对文件安全性扫描的功能，只需要创建一个新的负责文件安全性扫描的处理对象，并将其插入到合适的责任链位置即可，不需要对原有的文件大小检查、文件格式检查等相关代码进行大量修改，各个处理对象的职责明确，新功能的添加不会影响到已有功能的正常运行，使得整个系统能够轻松地应对业务的扩展和变化，不断适应新的需求，延长了系统的生命周期，降低了开发成本和维护成本。

方便进行错误处理和异常传播

在责任链中，如果某个处理对象在处理请求时出现错误或者异常，它可以选择在自身进行处理，也可以将异常沿着链条继续传递下去，让后续更合适的处理对象或者统一的异常处理机制来处理。比如在一个网络请求处理链中，先是进行请求参数验证的处理对象，如果发现参数不符合要求可以直接返回错误信息给请求发送者，也可以将异常传递给下一个负责网络连接建立的处理对象，由它根据具体情况决定是重新发起请求还是将异常继续传递给后续负责解析响应数据的处理对象等，这样可以构建一个更完善的错误处理体系，提高了系统对异常情况的应对能力和健壮性，保证了在出现问题时能够合理地处理和反馈，提升用户体验。

Java 域的关键字以及区别

Java 中的域指的是类中的成员变量，用于存储对象的状态。常见的关键字有 public、private、protected、default（默认，即不写任何修饰符）等，它们的区别如下：

public

被 public 修饰的成员变量可以在任何地方被访问，包括不同的类、不同的包。它提供了最大的访问权限，通常用于公开的、供外部使用的成员变量。

private

private 修饰的成员变量只能在当前类内部访问，外部类无法直接访问。这实现了对成员变量的严格封装，隐藏了类的内部实现细节，提高了代码的安全性和可维护性。

protected

protected 修饰的成员变量可以在当前类及其子类中访问，即使子类在不同的包中也可以访问。它提供了一种介于 public 和 private 之间的访问权限，适用于需要在继承体系中共享的成员变量。

default

如果成员变量没有使用任何修饰符，那么它具有默认的访问权限，只能在当前包内访问。这种访问权限限制了成员变量的可见性，使得在包外部无法直接访问，从而实现了一定程度的封装。

java 权限的四种不同（public，private，protect，和默认的）

Java 中的这四种访问权限修饰符在控制类、成员变量和方法的访问范围上有明显区别：

public

具有最广泛的访问权限，可被任何类访问，无论是在同一个包中还是在不同的包中。常用于定义公共的接口、工具类或常量等，方便其他类进行调用和使用。

private

访问权限最严格，只能在定义它的类内部访问。常用于类的内部实现细节，如私有成员变量和私有方法，这些成员不希望被外部类直接访问和修改，以保证类的封装性和安全性。

protected

允许在当前类及其子类中访问，即使子类在不同的包中也可以。主要用于在继承关系中，让子类可以访问父类的特定成员，同时又限制了外部类的访问，体现了一定的继承和封装的平衡。

默认（不写修饰符）

只能在当前包内访问，对于包外的类是不可见的。这种访问权限适用于在包内部共享的成员，但又不希望被包外的类访问，有助于实现包的封装和模块化。

面向对象对于面向过程有什么优势

面向对象编程（OOP）相对于面向过程编程（POP）具有以下优势：

代码的可维护性更高

在面向对象编程中，代码是围绕着对象和类组织的，每个类都有自己的职责和功能。当需要修改或扩展系统功能时，只需要在相应的类中进行修改，而不需要在整个程序中到处寻找相关的代码。

代码的可扩展性更好

面向对象编程通过继承和多态等特性，使得代码具有更好的扩展性。可以通过创建新的类来继承现有的类，并重写或扩展其方法，以实现新的功能。

代码的复用性更强

面向对象编程将具有相同属性和行为的对象抽象成类，这些类可以在不同的场景中被复用。可以通过创建类的实例来使用其功能，而不需要重复编写相同的代码。

更符合人类的思维方式

面向对象编程以对象为中心，将现实世界中的事物抽象成对象，对象之间通过消息传递进行交互。这种编程方式更符合人类的思维方式，使得程序员更容易理解和设计程序。

更好的团队协作

在面向对象编程中，不同的程序员可以负责不同的类的开发和维护，类之间的接口清晰明了，降低了团队协作的难度。

内部类有哪些种类

Java 中的内部类主要有以下几种类型：

成员内部类

定义在类内部，与类的成员变量和方法处于同一级别。成员内部类可以访问外部类的所有成员，包括私有成员。它就像是外部类的一个成员，可以使用外部类的实例变量和方法，也可以有自己的成员变量和方法。

静态内部类

使用 static 修饰的内部类，它属于外部类本身，而不属于外部类的某个实例。静态内部类只能访问外部类的静态成员，不能访问外部类的非静态成员。它通常用于创建与外部类相关但不依赖于外部类实例的工具类或常量类等。

方法内部类

定义在方法内部的内部类，它的作用域仅限于该方法内部。方法内部类可以访问外部类的所有成员，也可以访问方法的局部变量，但局部变量必须是 final 或实际上是 final 的。

匿名内部类

没有显式的类名，通常是在创建对象的同时定义类的具体实现。匿名内部类一般用于只需要使用一次的类，它可以继承一个类或实现一个接口，并在其中实现相应的方法。匿名内部类通常用于简化代码，特别是在事件处理、回调函数等场景中经常使用。

如何实现文件的断点续传？

文件断点续传的实现主要依赖于在文件传输过程中记录已传输的位置，并在传输中断后从该位置继续传输。以下是一种常见的实现方式：

客户端：首先需要在本地记录已上传或下载的文件位置，通常可以将此信息存储在本地文件或数据库中。在上传或下载文件时，设置文件的起始位置和结束位置，通过 HTTP 协议的 Range 头字段来指定要获取或发送的文件范围。例如，在下载文件时，向服务器发送请求，请求头中添加 “Range: bytes = 已下载字节数 - 文件总字节数”，服务器根据此请求返回指定范围的文件内容，客户端接收到内容后将其追加到本地文件的相应位置。
服务器端：需要支持对文件的部分请求处理。当接收到带有 Range 头字段的请求时，服务器根据请求的范围从文件中读取相应的数据并返回给客户端。同时，服务器还需要处理文件的完整性校验，确保文件在断点续传后能够正确合并和完整可用。
断点续传的恢复机制：当传输中断后，下次传输时客户端首先检查本地记录的已传输位置，然后按照上述方式向服务器请求剩余部分的文件内容，服务器根据请求返回相应数据，客户端继续接收并写入文件，直到整个文件传输完成。

数据库三范式？

数据库三范式是设计关系型数据库时应遵循的规范，以减少数据冗余和提高数据的一致性、完整性。

第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项，即表中的每个字段都只能包含单一的值，不能再进行细分。例如，一个 “员工信息” 表中，“联系方式” 字段不能同时包含手机号码和家庭电话等多个信息，而应该将它们拆分成独立的字段，如 “手机号码” 和 “家庭电话” 字段。
第二范式（2NF）：在满足第一范式的基础上，要求非主属性完全依赖于主键，而不能部分依赖于主键。例如，在一个 “订单详情” 表中，主键是 “订单编号” 和 “商品编号” 的组合，如果表中存在 “商品价格” 字段，而 “商品价格” 只与 “商品编号” 有关，与 “订单编号” 无关，那么就不满足第二范式，应该将 “商品价格” 字段移到 “商品” 表中。
第三范式（3NF）：在满足第二范式的基础上，要求任何非主属性不依赖于其他非主属性，即不存在传递依赖。例如，在一个 “学生” 表中，有 “学号”“姓名”“班级编号” 和 “班级名称” 字段，“班级名称” 依赖于 “班级编号”，而 “班级编号” 又依赖于 “学号”，存在传递依赖，不满足第三范式，应该将 “班级名称” 字段移到 “班级” 表中，通过 “班级编号” 进行关联。

数据库中事务的特性，数据库事务是什么？

数据库事务是指作为单个逻辑工作单元执行的一系列数据库操作，这些操作要么全部成功执行，要么全部不执行，以确保数据库的一致性和完整性。事务具有以下四个特性，简称 ACID 特性：

原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不完成，不会结束在中间某个环节。例如，在银行转账业务中，从一个账户扣款和向另一个账户收款这两个操作必须作为一个整体完成，如果其中任何一个操作失败，整个事务就会回滚，两个账户的余额都不会改变。
一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态。在转账事务中，无论转账是否成功，数据库中的总金额应该保持不变，即数据的完整性和业务规则的一致性必须得到保证。
隔离性（Isolation）：多个事务并发执行时，一个事务的执行不能被其他事务干扰，各个事务之间相互隔离。例如，当多个用户同时对同一个账户进行操作时，每个用户的操作都应该独立进行，互不影响，就好像每个事务是在一个单独的数据库实例上执行一样。
持久性（Durability）：事务一旦提交，其对数据库的修改就应该永久保存到数据库中，即使系统出现故障也不应该丢失。例如，在转账事务提交后，即使数据库服务器突然崩溃，重新启动后，转账的结果也应该仍然存在于数据库中。

用 Java 处理事务，你能想到什么办法？

在 Java 中处理事务主要有以下几种常见的方法：

使用 JDBC 手动处理事务：通过获取数据库连接，调用连接的setAutoCommit(false)方法关闭自动提交模式，然后在一系列数据库操作后，根据操作的结果决定是调用commit()方法提交事务还是调用rollback()方法回滚事务。例如，在执行多条 SQL 语句更新数据库时，如果其中一条语句执行失败，就可以调用rollback()方法撤销之前所有的操作，保证数据的一致性。这种方式比较灵活，但需要手动编写大量的事务控制代码，容易出错。
使用 Spring 框架的事务管理：Spring 提供了强大的事务管理功能，通过声明式事务和编程式事务两种方式。声明式事务可以通过在配置文件中配置事务的属性，如事务的传播行为、隔离级别等，然后在需要事务管理的方法或类上添加相应的注解，如@Transactional，Spring 会自动为这些方法或类添加事务管理。编程式事务则是通过在代码中直接调用 Spring 的事务管理接口来手动控制事务的提交和回滚，适用于需要更精细控制事务的场景。
使用 Java EE 的事务管理：在 Java EE 应用中，可以使用容器管理事务（CMT），通过在 EJB 组件中使用@TransactionAttribute注解或在部署描述符中配置事务属性，由应用服务器自动管理事务的生命周期。这种方式适合于大型企业级应用，开发人员只需要关注业务逻辑，事务管理由容器自动完成，但对应用服务器的依赖较大。

内存分页现象和置换算法比较？

内存分页是操作系统管理内存的一种方式，它将内存空间划分为固定大小的页框，将进程的地址空间划分为同样大小的页面，以便于内存的分配和管理。当内存空间不足时，需要使用置换算法来选择将哪些页面置换出内存，以腾出空间给新的页面。以下是几种常见的置换算法及其比较：

先进先出置换算法（FIFO）：该算法总是淘汰最先进入内存的页面，即选择在内存中驻留时间最长的页面进行置换。优点是实现简单，易于理解和实现。但它可能会淘汰经常使用的页面，导致页面置换频繁，降低系统性能，尤其在页面访问顺序具有局部性的情况下表现不佳。
最近最久未使用置换算法（LRU）：该算法根据页面最近的使用情况来选择置换页面，淘汰最近最长时间未被使用的页面。它的优点是能够较好地反映程序的局部性原理，减少页面置换的次数，提高系统性能。但实现起来相对复杂，需要记录页面的访问时间顺序，通常需要使用额外的数据结构来实现，如链表或栈等。
最佳置换算法（OPT）：该算法会选择未来最长时间内不会被访问的页面进行置换，是一种理想情况下的最优算法，能够保证最低的缺页率。但实际上无法预知页面的未来访问情况，所以该算法无法真正实现，只是作为一种衡量其他置换算法性能的标准。
时钟置换算法（CLOCK）：该算法是一种近似 LRU 的算法，它将页面组成一个环形链表，类似于时钟的表盘，页面有一个访问位，当页面被访问时，访问位被置为 1。置换时，从当前指针位置开始扫描，选择第一个访问位为 0 的页面进行置换，如果扫描一圈都没有找到访问位为 0 的页面，则将所有页面的访问位清 0 后再进行扫描。它的优点是实现相对简单，性能较好，不需要记录页面的访问时间顺序，只需要一个访问位来标记页面的使用情况。

不同的置换算法在不同的应用场景下有不同的表现，需要根据具体情况选择合适的置换算法，以提高系统的性能和内存利用率。

操作系统中页面置换算法

页面置换算法是在内存空间不足时，决定将哪些页面调出内存，以便为新的页面腾出空间的算法。常见的有以下几种：

先进先出置换算法（FIFO）：总是淘汰最先进入内存的页面。该算法实现简单，但可能会产生 Belady 异常，即随着分配的物理块数增加，缺页次数反而增加。例如，在一个进程的页面访问序列为 1、2、3、4、1、2、5、1、2、3、4、5，当物理块数为 3 时，采用 FIFO 算法可能会导致多次不必要的页面置换。
最近最久未使用置换算法（LRU）：选择最近最长时间未访问过的页面进行淘汰。它能较好地反映程序的局部性原理，但实现成本较高，需要额外的硬件支持或较多的时间开销来记录页面的访问顺序。例如，在上述页面访问序列中，若采用 LRU 算法，会优先淘汰长时间未被访问的页面 3 等，缺页率相对较低。
最佳置换算法（OPT）：淘汰未来最长时间内不会被访问的页面。这是一种理想的算法，能保证最低的缺页率，但实际上无法预知未来的页面访问情况，所以只能作为一种理论上的参考。
时钟置换算法（CLOCK）：是一种近似 LRU 的算法，它为每个页面设置一个访问位，将所有页面组织成一个环形链表。当需要置换页面时，从当前指针位置开始扫描，选择第一个访问位为 0 的页面进行淘汰。如果扫描一圈都没有找到访问位为 0 的页面，则将所有页面的访问位清 0 后再进行扫描。该算法性能较好，实现相对简单。

操作系统死锁，分页，造成死锁的必要条件（互斥，占有和等待，不抢占，环路等待），操作系统虚拟内存和物理内存关系，内存分页算法，虚拟内存和物理内存有什么区别？，oom 和内存溢出的关系，什么情况下内存溢出，具体分析，怎么计算需要多少虚拟内存

死锁及必要条件：死锁是指多个进程在运行过程中因争夺资源而造成的一种僵局，若无外力作用，这些进程都将无法继续向前推进。造成死锁的必要条件有互斥，即资源在一段时间内只能被一个进程占用；占有和等待，指进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有；不抢占，进程已获得的资源在未使用完之前不能被抢占；环路等待，存在一组进程，它们互相等待对方所占有的资源。
虚拟内存和物理内存关系：虚拟内存是一种计算机系统内存管理技术，它使得应用程序认为自己拥有连续的可用内存空间，而实际上这些内存可能是分散在物理内存和磁盘上的。物理内存是计算机实际的硬件内存，是真实存在的存储设备。虚拟内存通过页表等机制将虚拟地址映射到物理地址，实现了对物理内存的有效利用和扩展，当程序访问虚拟内存中的某个地址时，操作系统会将对应的物理内存页加载到内存中，如果物理内存不足，还会进行页面置换等操作。
内存分页算法：常见的内存分页算法有 FIFO、LRU、CLOCK 等，这些算法在前面已经详细介绍过，主要用于在物理内存不足时决定将哪些页面置换出内存，以提高内存的利用率和系统的性能。
虚拟内存和物理内存区别：物理内存是实实在在的硬件存储设备，容量有限且访问速度快；虚拟内存是一种逻辑上的内存空间，通过在磁盘上开辟空间来扩展内存容量，访问速度相对较慢。虚拟内存为每个进程提供了独立的、连续的地址空间，使得多个进程可以共享物理内存，同时也方便了内存的管理和保护。
OOM 和内存溢出关系及内存溢出情况分析：OOM 即内存溢出错误，是指程序在运行过程中申请的内存超过了系统所能提供的最大内存限制。内存溢出通常是由于程序中存在内存泄漏、不合理的内存分配、大量数据的加载等原因导致的。例如，在 Java 中，如果不断地创建对象而没有及时释放，或者加载了过大的文件到内存中，都可能导致内存溢出。当内存溢出发生时，系统会抛出 OOM 异常，导致程序崩溃。
虚拟内存计算：计算所需的虚拟内存大小需要考虑多个因素，包括系统的物理内存大小、运行的程序数量和类型、每个程序的内存需求等。一般来说，可以通过对系统的历史内存使用情况进行分析，结合当前运行的程序和预计的负载，来估算所需的虚拟内存大小。但这只是一个大致的估算，实际情况可能会因程序的运行时行为而有所不同。

如何评估一个需求多久能够做完

需求分析：首先要对需求进行全面、深入的分析，明确需求的具体内容、功能要求、业务流程等。将需求分解为具体的任务和子任务，确定每个任务的大致工作量和难度。例如，对于一个电商 APP 的新功能需求，需要分析涉及的页面设计、接口开发、数据库修改、业务逻辑实现等各个方面的具体工作。
技术评估：根据需求的技术要求，评估所需的技术栈、开发工具、框架等。考虑是否需要引入新的技术或对现有技术进行升级，以及这些技术的学习成本和开发难度。如果涉及到复杂的算法、高性能要求或与外部系统的集成，需要额外考虑技术风险和可能出现的问题。
人员能力和资源评估：了解团队成员的技术水平、经验和专业领域，合理分配任务给合适的人员。同时，考虑项目所需的硬件资源、软件许可证、测试设备等是否充足。如果团队成员对某些技术不熟悉，可能需要安排培训时间，这也会影响需求的完成时间。
历史数据参考：回顾以往类似项目或需求的开发经验，参考完成时间、遇到的问题及解决方案等。例如，如果之前开发过类似的功能模块，可以根据当时的开发情况和实际用时，对当前需求的完成时间进行大致估算，并根据实际情况进行调整。
风险评估：识别可能影响需求完成时间的风险因素，如需求变更、技术难题、人员变动、外部依赖等。对每个风险因素进行评估，制定相应的应对措施和预案。例如，对于可能出现的需求变更，与业务部门提前沟通，明确变更流程和时间节点，尽量减少对项目进度的影响。

给出的时间比你想象的少会怎么做

重新评估任务优先级：首先对需求中的各项任务进行重新梳理，根据业务重要性和紧急程度重新确定优先级。将核心功能和关键业务流程放在首位，确保在有限的时间内先完成最重要的部分。对于一些非核心的功能或优化项，可以适当推迟或简化，以集中精力满足主要需求。
优化开发流程：检查当前的开发流程，看是否存在可以优化的环节。例如，减少不必要的会议和沟通环节，采用更高效的协作工具和沟通方式，避免因信息传递不畅而浪费时间。同时，优化代码审查和测试流程，确保在保证质量的前提下提高效率。可以采用自动化测试工具，增加测试的覆盖范围和频率，及时发现和解决问题，减少后期返工的时间。
寻求外部资源和帮助：考虑是否可以借助外部的资源和力量来加快项目进度。例如，引入外部的技术专家进行技术难题的攻关，或者使用第三方的开源库、工具等，减少自行开发的时间和工作量。如果有合适的外包团队，也可以将部分非核心的任务外包出去，以分担内部团队的压力。
调整团队工作时间和方式：在合理范围内，适当调整团队的工作时间和工作方式。例如，采用加班、弹性工作时间等方式，增加团队的有效工作时间。同时，鼓励团队成员之间的协作和互助，采用结对编程、代码共享等方式，提高工作效率和代码质量。但要注意避免过度加班导致团队成员疲劳和工作效率下降，需要合理安排休息时间。
与相关方沟通协调：及时与业务部门、上级领导等相关方进行沟通，说明当前时间紧张的情况和可能面临的风险。争取得到他们的理解和支持，看是否可以对需求进行进一步的简化或调整。同时，与其他相关的团队或部门协调资源和工作进度，避免因外部依赖而耽误时间。

给出的时间比你想象的多会怎么做？

如果给定的时间比我想象的多，首先我会利用额外的时间对项目进行更深入的需求分析和设计优化。重新审视整个项目的架构和流程，看是否有可以进一步改进的地方，以提高项目的可扩展性、可维护性和性能。例如，对于一个 Android 应用的开发，如果时间充裕，我会考虑采用更先进的架构模式，如 MVVM 或 Clean Architecture，对代码结构进行优化。

其次，我会加强代码的质量把控，增加更多的单元测试和集成测试用例，尽可能覆盖更多的边界情况和异常情况，以确保代码的稳定性和可靠性。同时，还可以进行代码的重构，消除代码中的异味，提高代码的可读性和可理解性。

另外，我会利用多余的时间进行更充分的用户体验优化。与产品团队和设计团队密切合作，收集更多的用户反馈，对界面进行精细调整，优化交互流程，提升应用的易用性和用户满意度。

最后，我会对项目进行更全面的性能优化。使用性能分析工具，如 Android Profiler，对应用的内存使用、CPU 占用、网络请求等进行详细分析，找出潜在的性能瓶颈并进行优化，如图片加载优化、数据库查询优化、算法优化等，以确保应用在各种设备上都能流畅运行。

项目中遇到的让你棘手的问题？多久解决，怎么解决？

在之前的一个 Android 项目中，遇到过一个棘手的内存泄漏问题。应用在长时间运行后，会出现频繁的卡顿和崩溃现象。

首先，我使用了 Android Studio 自带的 Memory Profiler 工具对内存进行监测和分析，发现是在处理一些图片加载和缓存的逻辑时，存在对 Bitmap 对象的不当引用，导致无法及时释放内存。

然后，我对相关的代码进行了仔细的排查，发现是在自定义的图片加载库中，没有正确地处理 Bitmap 的回收机制。我参考了一些开源的图片加载库的实现方式，如 Glide 和 Picasso，对自己的代码进行了重构。

经过大约一周的时间，不断地测试、调整和优化，最终解决了这个内存泄漏问题。在解决过程中，我还与团队成员进行了多次讨论和交流，借鉴了他们的经验和建议，同时也查阅了大量的技术文档和博客，不断拓宽自己的思路和知识面。

你现在如何处理崩溃日志？

当遇到崩溃日志时，首先我会收集尽可能多的信息，包括崩溃发生的时间、设备型号、系统版本、应用版本等。这些信息对于定位问题非常重要。

然后，我会仔细分析崩溃日志中的堆栈信息，从异常的类型和抛出的位置入手，逐步追溯到导致崩溃的代码片段。通常，崩溃日志会明确指出是哪一行代码出现了问题，以及在什么情况下触发了异常。

对于一些常见的崩溃原因，如空指针异常、数组越界异常等，我会直接在代码中查找可能出现问题的地方，检查相关的变量赋值和逻辑判断是否正确。对于一些比较复杂的问题，可能需要结合代码的上下文和业务逻辑进行深入分析。

在定位到问题后，我会及时进行修复，并进行充分的测试，确保问题得到彻底解决。同时，我会将崩溃日志和解决过程记录下来，以便后续查阅和总结经验教训，避免类似的问题再次出现。

在公司工作中如何学习？何时学习？怎么学习？学习渠道？

在公司工作中，我会利用碎片化的时间和工作之余的时间进行学习。例如，在完成一个任务后，利用休息的间隙阅读一些技术文章或博客，了解行业的最新动态和技术趋势。

在日常工作中，当遇到新的技术难题或需要使用新的技术框架时，我会主动进行学习。通过阅读官方文档、参考开源项目、参加技术培训等方式，快速掌握相关的知识和技能。

我还会定期参加公司内部的技术分享会和交流活动，与同事们分享自己的经验和心得，同时也学习他们的优秀经验和做法。此外，我也会利用在线学习平台，如 Coursera、Udemy 等，学习一些系统的课程，提升自己的专业素养。

学习渠道方面，除了上述提到的，我还会关注一些知名的技术论坛，如 Stack Overflow、掘金等，在上面与其他开发者交流和学习。同时，我也会阅读一些经典的技术书籍，深入学习和理解计算机科学的基础知识和原理。

运行时注解有什么好处，注解有哪些类型，了解过吗，运行时注解是运行在哪里的

运行时注解的好处有很多。首先，它可以在不修改原有代码逻辑的基础上，为代码添加额外的元数据信息，实现对代码的灵活配置和扩展。例如，在 Android 开发中，可以使用运行时注解来实现依赖注入、事件绑定等功能，减少了大量的模板代码，提高了代码的可读性和可维护性。

其次，运行时注解可以方便地实现一些 AOP（面向切面编程）的功能，如权限检查、日志记录、性能监控等。通过在方法或类上添加注解，可以在运行时动态地切入相应的逻辑，而不需要在每个方法中都编写重复的代码。

注解的类型主要有以下几种：

元注解：用于修饰其他注解，如 @Retention、@Target、@Documented、@Inherited 等，它们定义了注解的保留策略、作用目标、是否生成文档以及是否可继承等特性。
自定义注解：开发者根据自己的需求定义的注解，通常用于特定的业务场景，如 @Autowired、@RequestMapping 等。
Java 内置注解：如 @Override、@Deprecated、@SuppressWarnings 等，这些注解具有特定的语义和用途，用于标识方法的重写、类或方法的过时以及抑制编译器的警告等。

运行时注解是在程序运行期间被解析和处理的。在 Java 中，通常使用反射机制来获取类、方法、字段等元素上的注解信息，并根据注解的定义进行相应的处理。在 Android 开发中，一些框架如 ButterKnife、Retrofit 等就是利用运行时注解和反射机制来实现的，它们在运行时解析注解并生成相应的代码，以实现诸如视图绑定、网络请求等功能。

介绍 Flutter，能谈一谈 Flutter 的优势吗

Flutter 是谷歌开源的移动应用开发框架，使用 Dart 语言进行开发。它具有跨平台特性，一套代码可以同时在 Android 和 iOS 等多个平台上运行，大大减少了开发成本和时间。其热重载功能可以让开发者在修改代码后立即看到效果，无需重新编译整个应用，极大地提高了开发效率。Flutter 的性能表现出色，它通过自己的渲染引擎直接绘制 UI，避免了原生平台的 UI 组件渲染开销，能够实现流畅的动画效果和快速的响应速度。在 UI 设计方面，Flutter 提供了丰富的、高度可定制的 UI 组件，开发者可以轻松创建出美观、独特的用户界面，并且可以保证在不同平台上的一致性。此外，Flutter 还支持插件化开发，能够方便地调用原生平台的功能，如摄像头、地理位置等，充分利用原生平台的能力，同时又保持了跨平台的优势。

网络框架 Volley 的使用，有哪些类，其他网络框架有哪些，与 Volley 的区别

Volley 是一个用于 Android 的异步网络请求框架，使用起来较为方便。它主要包含 RequestQueue 类，用于管理网络请求队列；StringRequest、JsonObjectRequest 等请求类，用于发送不同类型的网络请求并处理响应；Response 类用于表示服务器的响应结果等。其他常见的网络框架有 OkHttp 和 Retrofit。OkHttp 是一个高效的 HTTP 客户端，支持 HTTP/2 和 SPDY 协议，提供了连接池、拦截器等功能，在网络连接和请求性能方面表现出色，它通常作为底层网络通信的基础库，而 Volley 更侧重于提供一种简单方便的网络请求处理方式，适用于一些简单的网络请求场景。Retrofit 是一个基于 OkHttp 的网络请求框架，它通过注解的方式来定义网络请求接口，使得网络请求的代码更加简洁和易于维护，与 Volley 相比，Retrofit 在处理复杂的网络请求和接口定义方面更有优势，而 Volley 在一些简单的 GET、POST 请求场景下可能更加轻便易用。

什么是长连接

长连接是一种网络连接方式，在通信双方建立连接后，在较长时间内保持连接状态，而不是在每次数据传输完成后立即断开连接。在长连接模式下，连接一旦建立，客户端和服务器之间可以随时进行数据交互，无需重复建立连接的过程，减少了连接建立和销毁的开销，提高了数据传输的效率。常用于实时性要求较高的应用场景，如即时通讯应用中，客户端和服务器需要保持长时间的连接，以便及时接收和发送消息；在线游戏中，玩家的操作和游戏状态需要实时同步，长连接可以确保数据的及时传输。长连接可以通过多种协议实现，如 HTTP 长连接可以在 HTTP 请求头中设置特定的字段来保持连接，而 TCP 长连接则是在传输层通过保持 TCP 连接的状态来实现。

SharedPreference 里 apply 和 commit 的区别

SharedPreference 是 Android 中用于存储轻量级键值对数据的一种机制。apply 和 commit 都是用于将数据保存到 SharedPreference 中的方法，但存在一些区别。commit 方法是同步的，它会立即将数据写入磁盘文件中，如果写入过程出现错误，会返回 false，调用者可以根据返回值判断写入是否成功，通常用于需要确保数据立即持久化的场景，比如在保存重要的配置信息后，需要立即确认数据是否成功保存到磁盘，以保证下次应用启动时能够正确读取到最新的配置。apply 方法是异步的，它会先将数据写入内存中的缓存，然后在合适的时机异步地将数据写入磁盘文件，不会返回写入结果，通常适用于一些对数据保存的及时性要求不高的场景，比如保存一些临时的用户偏好设置，即使数据没有立即写入磁盘，也不会对应用的正常运行产生太大影响，而且由于是异步操作，不会阻塞主线程，提高了应用的响应性能。

FragmentManager 里事务的作用

FragmentManager 中的事务有着至关重要的作用。它主要用于对 Fragment 进行添加、移除、替换、显示、隐藏等操作的管理，以此来动态地改变 Activity 中 Fragment 的布局和显示状态。

例如，在一个具有多页面切换功能的应用中，通过 FragmentManager 的事务，可以在不同的业务场景下灵活地添加新的 Fragment 来展示不同的内容页面，或者替换掉当前显示的 Fragment 以切换到另一个功能模块对应的页面。当需要根据用户的操作隐藏某个暂时不用的 Fragment，节省内存资源同时保持界面简洁时，就可以利用事务来实现隐藏操作。而且在处理 Fragment 回退栈方面，事务也起到关键作用，比如模拟类似 Activity 的返回栈效果，将添加或替换 Fragment 的操作记录到回退栈中，用户点击返回键时能按照正确的顺序恢复之前的 Fragment 显示状态，确保了用户操作的连贯性和界面状态的合理管理。另外，在处理复杂的界面布局，涉及多个 Fragment 组合展示，且需要动态调整它们的显示顺序、可见性等情况时，FragmentManager 的事务能保证这些操作的原子性，要么所有操作都成功执行，要么都不执行，避免出现界面显示错乱等问题，保障了整个应用界面的稳定性和交互逻辑的正确性。

ViewInflater.inflate 里 attachToRoot 参数的作用

ViewInflater 的 inflate 方法中的 attachToRoot 参数在视图的加载和添加过程中有着明确的作用。

当 attachToRoot 设置为 true 时，意味着加载的视图将会被直接添加到指定的根视图中，也就是成为根视图的子视图。例如，在自定义 ViewGroup 时，通过 LayoutInflater 加载一个布局文件生成视图，如果将 attachToRoot 设为 true，并传入自定义 ViewGroup 作为根视图，那么加载出来的视图就会立即成为这个自定义 ViewGroup 的子元素，并且会按照布局文件中的布局规则在其中进行布局排列，同时会触发相应的布局相关的生命周期方法等，比如 onMeasure、onLayout 等方法会根据其在新的父视图中的位置和尺寸要求等进行调用，使其融入到整个视图层次结构中。

而当 attachToRoot 设置为 false 时，只是单纯地将布局文件解析并创建对应的视图对象，但不会将其添加到任何根视图中，只是返回这个解析好的视图。这种情况常用于先创建视图，后续再根据业务逻辑等情况，选择合适的时机和根视图去进行添加操作，比如在动态创建多个相似的视图，然后根据用户的选择或者其他条件决定将它们添加到不同的父视图位置时，就可以先以 false 的方式加载视图，方便后续灵活操作，避免了不必要的过早添加导致的布局灵活性受限等问题。

子线程更新 UI 的方式，AsyncTask 介绍，有哪些方法

子线程更新 UI 的方式

在 Android 中，直接在子线程更新 UI 是不被允许的，会抛出异常，因为 UI 操作必须在主线程进行，不过有几种常见的间接方式来实现子线程更新 UI。一种是通过 Handler 机制，先在主线程创建 Handler 对象，然后在子线程中利用这个 Handler 发送消息或者提交 Runnable 任务到主线程的消息队列，当消息被主线程取出并处理时，就可以在对应的处理逻辑中进行 UI 更新操作了，比如更新 TextView 的文本、改变 Button 的状态等。另外，也可以使用 Activity 或者 Fragment 提供的 runOnUiThread 方法，在子线程中调用这个方法并传入一个 Runnable 对象，内部会将其切换到主线程去执行，从而实现 UI 更新。还有像使用 View.post 方法，在子线程中针对某个具体的 View 对象调用 post 方法并传入 Runnable，同样会将该任务切换到主线程执行，完成 UI 更新，常用于针对某个具体视图的更新场景。

AsyncTask 介绍

AsyncTask 是 Android 提供的一个抽象类，用于简化在后台线程执行耗时操作并在主线程更新 UI 的过程，使得异步任务的处理变得更加方便和规范。它基于线程池和 Handler 机制实现。

AsyncTask 的方法

onPreExecute()：这个方法在异步任务开始执行前在主线程被调用，通常用于做一些初始化的准备工作，比如显示一个进度条，提示用户操作正在进行等。
doInBackground(Params...)：是在后台线程执行的方法，这里面放置耗时的操作，比如网络请求、文件读取等，它可以接收参数，并且可以通过 publishProgress 方法来发布进度，该方法会触发 onProgressUpdate 方法的调用。
onProgressUpdate(Progress...)：在主线程被调用，用于接收 doInBackground 方法发布的进度信息，并根据进度进行相应的 UI 更新，比如更新进度条的进度展示等。
onPostExecute(Result)：在后台任务执行完毕后在主线程被调用，用于根据后台任务的结果来进行最终的 UI 更新，比如将网络请求获取到的数据展示到界面上相应的控件中。

kHttp 原理？Retrofit 原理？为何用代理？代理的作用是什么？ButterKnife 原理？用到反射吗？为什么？

kHttp 原理

kHttp 是一个相对轻量级的网络请求库，它底层基于 Java 的 HttpURLConnection（或者在 Android 中可以切换到 OkHttp 等底层实现）来建立与服务器的网络连接。它通过封装相关的网络请求操作，将复杂的连接建立、请求发送、响应接收等流程进行简化，对外提供简洁的 API 供开发者使用。比如开发者只需要简单地配置请求的 URL、请求方法（GET、POST 等）、请求参数等信息，kHttp 就能自动完成与服务器的交互过程，并且可以对响应数据进行解析等操作，把获取到的结果以合适的形式返回给开发者，方便在 Android 应用中进行网络相关的数据获取和交互。

Retrofit 原理

Retrofit 是一个基于注解的网络请求框架，其核心原理是通过使用 Java 的动态代理机制来生成接口的代理对象。开发者先定义一个网络请求接口，在接口中通过注解（如 @GET、@POST 等）来描述请求的相关信息，比如请求的 URL 路径、请求参数的传递方式等。Retrofit 在运行时会利用动态代理为这个接口创建代理对象，当调用接口中的方法时，实际上是由代理对象来处理，代理对象根据方法上的注解以及传入的参数等信息，将其组装成一个实际的网络请求，然后借助底层的网络通信库（通常是 OkHttp）去发送请求并接收响应，最后将响应结果按照方法的返回类型进行解析和转换，返回给调用者，实现了简洁高效的网络请求代码编写和执行流程。

为何用代理及代理的作用

在 Retrofit 中使用代理主要是为了实现接口与实际网络请求操作的解耦，代理可以拦截接口方法的调用，根据注解等信息动态地构建网络请求，无需开发者手动去编写大量复杂的网络请求代码，比如拼接 URL、设置请求头、处理请求参数等，让网络请求的代码编写更符合面向接口编程的思想，代码更加简洁易读、易于维护和扩展。代理能够在不改变原有接口定义的基础上，灵活地添加各种功能，比如添加统一的请求拦截、响应处理等逻辑，提升了网络请求的灵活性和可管理性。

ButterKnife 原理

ButterKnife 是一款用于 Android 的视图绑定框架，它的原理是基于 Java 的注解和反射机制。开发者通过在 Activity、Fragment 等组件中使用特定的注解（如 @BindView 等）来标记需要绑定的视图，ButterKnife 在编译期会通过注解处理器去扫描这些注解，生成对应的辅助类，这些辅助类中包含了通过反射获取视图实例并进行绑定的代码逻辑。在运行时，相关组件初始化时，会调用这些辅助类的方法，利用反射机制找到对应的视图并完成绑定操作，从而实现了无需手动编写大量的 findViewById 代码就能快速方便地绑定视图的功能，提高了开发效率，让代码更加简洁。

用到反射的原因

ButterKnife 用到反射主要是为了根据开发者添加的注解信息去动态地查找和操作对应的视图对象。因为注解本身只是一种元数据，不会主动执行什么操作，通过反射可以在运行时获取类的结构信息，比如类中的成员变量、方法等，从而依据注解所标记的情况，找到对应的视图 ID 并获取视图实例，进行绑定。这样就能实现代码的自动化生成和视图绑定的功能，基于注解和反射的配合，减少了手动编写重复的视图查找代码的工作量，提升了开发的便捷性和代码的整洁度。

JVM 内存模型？性能调优？

JVM 内存模型

JVM 内存模型主要划分了多个不同的区域，各有其功能和特点。

程序计数器：它是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器，用于记录线程执行的位置，方便线程切换后能继续正确执行。每个线程都有独立的程序计数器，并且它是线程私有的，不存在线程安全问题，因为它只是跟踪本线程的执行进度。
Java 虚拟机栈：用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个线程在创建时都会创建对应的虚拟机栈，同样是线程私有的。在方法调用时，会创建对应的栈帧，放入栈中，方法执行完毕后栈帧出栈，它与方法的执行紧密相关，在执行过程中涉及到的局部变量等都在这里存储，并且规定了栈的大小，如果出现递归调用过深等情况，可能会出现栈溢出异常。
本地方法栈：和 Java 虚拟机栈类似，不过它是为本地方法（用非 Java 语言编写的方法，比如 C 或 C++ 语言编写的方法，通过 JNI 调用到 Java 中）服务的，每个线程也有自己独立的本地方法栈，也是线程私有的，用于存储本地方法执行相关的一些信息。
堆：是 JVM 所管理的内存中最大的一块，用于存放对象实例以及数组等数据，它是被所有线程共享的区域，正因如此，在多线程环境下如果没有合适的同步机制，对堆中对象的访问容易出现线程安全问题。垃圾回收机制主要就是针对堆内存进行对象的回收管理，避免内存泄漏等情况，以保证内存的有效利用。
方法区：用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据，它也是线程共享的区域，像类的常量池就在方法区中，在不同线程访问类的静态变量等情况时，就是在访问方法区中的数据，同样如果没有相应的并发控制，也可能出现数据不一致等问题。

JVM 性能调优

内存调优方面：可以通过调整堆内存的大小参数（如 - Xms 初始堆大小，-Xmx 最大堆大小等），根据应用的实际内存使用情况，合理设置初始值和最大值，避免因为内存过小导致频繁的垃圾回收影响性能，也防止内存过大造成资源浪费。同时，选择合适的垃圾回收器也很关键，比如对于响应要求较高的应用，G1 垃圾回收器可以较好地控制停顿时间，通过合理配置其参数（如期望的最大停顿时间等）来优化垃圾回收过程，减少对应用运行的影响。还可以通过分析内存使用情况，查看是否存在内存泄漏问题，利用工具如 Java VisualVM 等观察对象的创建和销毁情况，对于长期存活的不必要对象及时排查和修复代码，减少内存占用。
代码层面调优：优化算法逻辑，避免复杂度过高的循环嵌套、递归等情况，减少不必要的计算量。合理使用缓存机制，对于一些频繁获取但计算成本高的数据，可以缓存起来，下次直接使用缓存结果，提高执行效率。在多线程环境下，正确使用同步机制，避免过度的锁竞争，比如可以缩小锁的范围，采用更细粒度的锁控制，或者使用并发容器替代传统的非并发容器，提升多线程并发执行的性能。另外，及时关闭一些不必要的资源，如数据库连接、文件流等，避免资源占用过多影响性能。
JVM 参数调优：除了前面提到的堆内存大小参数，还可以调整其他参数，比如 - XX:SurvivorRatio 用于调整新生代中 Eden 区和 Survivor 区的比例，根据对象的存活率等情况合理设置，优化新生代的内存分配和垃圾回收效率；-XX:NewRatio 用于调整新生代和老年代的比例，不同的应用场景对新生代和老年代的内存需求不同，通过合理设置能让内存分配更符合实际需求，提高整体性能。并且可以通过添加一些监控和诊断参数，如 - XX:+PrintGCDetails 来打印详细的垃圾回收信息，以便更好地分析和优化 JVM 的运行状态。

知道哪些数据结构，树有哪些树以及特征？树层次遍历和深度遍历怎么用？，有哪些排序算法？有哪些查找算法？

知道的数据结构

熟悉多种常见的数据结构，包括线性的数据结构如数组、链表、栈和队列等。数组是连续存储元素的结构，能通过下标快速访问元素，但插入和删除操作相对复杂且可能涉及元素移动；链表则通过节点间的指针连接，插入和删除方便，但查找特定元素相对耗时。栈遵循后进先出原则，常用于函数调用、表达式求值等场景；队列是先进先出结构，在任务调度、消息传递等方面应用广泛。

还有非线性的数据结构如树和图。树是一种层次化的数据结构，节点间有父子关系，图则是由顶点和边构成，顶点之间通过边相连，可表示更为复杂的关系网络。

树的种类及特征

二叉树：每个节点最多有两个子节点，分为左子树和右子树，有很多衍生类型，比如满二叉树，其所有非叶子节点都有两个子节点，且所有叶子节点都在同一层；完全二叉树是除了最后一层节点外，其余各层节点数都达到最大值，且最后一层的节点都连续集中在最左边。
二叉搜索树：左子树上所有节点的值都小于根节点的值，右子树上所有节点的值都大于根节点的值，这样方便进行查找、插入和删除操作，基于其特性可快速定位元素所在位置。
平衡二叉树（如 AVL 树）：在二叉搜索树的基础上，通过调整节点的平衡因子（左右子树高度差），保证树的左右子树高度差绝对值不超过 1，从而避免树出现极端的不平衡情况，能保证较好的查找性能，时间复杂度基本稳定在 O (logn)。
红黑树：也是一种自平衡的二叉搜索树，通过将节点标记为红色或黑色，并遵循特定的规则来维持树的平衡，其插入、删除和查找操作的时间复杂度平均也能维持在较低水平，在很多底层数据结构实现以及编程语言的容器类中都有应用，比如 Java 中的 TreeMap、TreeSet 等底层部分是基于红黑树实现的。

树的层次遍历和深度遍历用法

层次遍历：通常借助队列来实现。从根节点开始，先将根节点入队，然后循环执行以下操作：每次取出队首节点，访问该节点，接着将其所有子节点依次入队，如此反复，直到队列为空。这样就能按照从上到下、从左到右的顺序依次访问树的各个节点，常用于需要按层处理节点的情况，比如打印树的每层节点信息或者计算树的高度等，是一种广度优先搜索的体现。
深度遍历：又分为先序遍历、中序遍历和后序遍历（针对二叉树而言）。先序遍历是先访问根节点，再递归访问左子树，最后递归访问右子树，常用于复制树或者按照特定顺序构建表达式树等场景；中序遍历是先访问左子树，再访问根节点，最后访问右子树，对于二叉搜索树来说，按照中序遍历得到的节点值序列是有序的，所以常应用于对二叉搜索树进行排序相关操作；后序遍历则是先访问左子树，再访问右子树，最后访问根节点，常用于计算树的节点个数、释放树节点的内存等操作，先处理子树再处理根节点符合一些递归处理逻辑。对于非二叉树的通用深度遍历，可以通过递归或者借助栈等数据结构来实现，沿着树的分支不断深入访问节点，直到达到叶子节点后回溯，再去探索其他分支，这是一种深度优先搜索的方式。

排序算法

冒泡排序：通过反复比较相邻的元素，如果顺序不对就进行交换，经过多轮比较和交换，使得最大（或最小）的元素像气泡一样逐渐 “浮” 到数组的一端，时间复杂度在最坏情况下为 O (n²)，但实现简单，适用于数据量较小且基本有序的情况。
选择排序：每一轮从待排序的数据元素中选出最小（或最大）的一个元素，存放在序列的起始位置，然后再从剩余未排序元素中继续选择，依次类推，直到所有元素都排序完毕，时间复杂度同样为 O (n²)，其特点是交换操作相对较少，不过不管初始数据如何，都需要进行固定轮次的选择操作。
插入排序：将待排序的元素插入到已经有序的部分序列中合适的位置，就像人们打牌时整理手牌一样，从第二个元素开始，依次将元素插入到前面已排好序的子序列中，时间复杂度在最好情况下可以达到 O (n)（数据本身有序时），最坏情况是 O (n²)，在处理基本有序的数据时效率相对较高。
快速排序：通过选择一个基准元素，将数组分为两部分，左边部分的元素都小于基准元素，右边部分的元素都大于基准元素，然后对这两部分分别递归进行同样的操作，直到整个数组有序，平均时间复杂度为 O (nlogn)，但在最坏情况下（如数据已经有序时）可能退化为 O (n²)，不过在实际应用中表现优秀，是一种常用的高效排序算法。
归并排序：采用分治法，先将数组不断分成两半，直到每个子数组只有一个元素，然后再将这些子数组两两合并，合并过程中保证合并后的子数组是有序的，不断合并直到得到最终有序的数组，时间复杂度稳定在 O (nlogn)，不过需要额外的空间来辅助合并操作，空间复杂度相对较高。
堆排序：利用堆这种数据结构（通常是二叉堆）的特性，先将数组构建成一个堆（最大堆或最小堆），然后每次取出堆顶元素（最大或最小元素），再调整堆使其保持堆的特性，重复此过程直到所有元素都取出，时间复杂度为 O (nlogn)，并且是一种原地排序算法，不需要额外太多空间。

查找算法

顺序查找：从数据结构的一端开始，逐个元素进行比较，直到找到目标元素或者遍历完整个数据结构为止，时间复杂度在最坏情况下为 O (n)，适用于数据量较小或者没有其他特殊结构的简单查找场景。
二分查找：要求数据必须是有序的，每次查找时将查找区间分为两部分，通过比较目标元素和中间元素的大小，确定下一步在哪个子区间继续查找，不断缩小查找范围，时间复杂度为 O (logn)，效率较高，但对数据的有序性有要求，常用于有序数组等数据结构的查找操作。
哈希查找：通过哈希函数将元素的关键字映射到一个固定大小的哈希表中，理想情况下可以在 O (1) 的时间复杂度内找到目标元素，但可能存在哈希冲突的情况，需要通过合适的冲突解决方法（如链地址法、开放地址法等）来处理，在处理大量数据且对查找速度要求较高的场景中应用广泛，比如在数据库索引等方面经常用到。

有哪些加密算法？

常见的加密算法有多种类型，以下是一些主要的介绍：

对称加密算法

DES（Data Encryption Standard）：它是一种比较经典的对称加密算法，使用同一个密钥进行加密和解密操作，加密时将明文按照固定长度分组，然后通过一系列复杂的置换、替换等操作生成密文，解密则是逆向的过程。不过随着计算机性能的提升，其 56 位的密钥长度安全性逐渐不足，现在已较少单独使用。
3DES（Triple DES）：是对 DES 的改进，通过对数据进行三次 DES 加密操作，使用不同的密钥组合（可以是三个不同密钥或者两个不同密钥，共 24 位有效密钥长度），在一定程度上提高了加密的安全性，能抵御更强的攻击，但由于计算量相对较大，效率方面会有所影响。
AES（Advanced Encryption Standard）：目前应用非常广泛的对称加密算法，密钥长度可以有 128 位、192 位、256 位等多种选择，安全性较高，加密和解密速度快，它采用了分组加密的方式，将明文分成固定大小的块，通过多轮的变换操作生成密文，在众多需要对数据进行高效且安全加密的场景，如文件加密、网络通信加密等方面都有使用。

非对称加密算法

RSA（Rivest-Shamir-Adleman）：这是最具代表性的非对称加密算法之一，它基于数论中的大整数分解难题等数学原理，有一对密钥，分别是公钥和私钥，公钥可以公开，用于对数据进行加密，私钥则由持有者保密，用于解密。同时，私钥也可用于数字签名，公钥用于验证签名，在身份认证、安全通信、电子签名等诸多领域有着广泛应用，不过其加密和解密的计算量相对较大，效率不如对称加密算法高，通常适合对少量关键数据进行加密处理。
Diffie-Hellman 密钥交换算法：主要用于在不安全的网络环境中，双方能够安全地协商出一个共享的对称密钥，双方无需事先知道对方的私钥，通过公开的参数和各自的私钥进行计算，最终得到相同的共享密钥，然后可以使用这个共享密钥进行后续的对称加密通信，常用于在网络通信建立加密连接的初始阶段。

哈希算法（严格来说不算加密算法，但常用于数据完整性验证等与安全相关场景）

MD5（Message Digest Algorithm 5）：能将任意长度的数据转换为一个 128 位的哈希值（通常用十六进制表示），计算速度较快，但由于其存在一些安全性漏洞，如容易出现哈希碰撞等情况，现在已经不适合用于对安全性要求较高的数据完整性验证等场景，不过在一些对安全性要求不高的简单数据校验等方面仍可能会被使用。
SHA（Secure Hash Algorithm）系列：包括 SHA-1、SHA-256、SHA-384 等多种版本，SHA-1 输出 160 位的哈希值，不过也逐渐被发现存在安全隐患；SHA-256 等后续版本安全性更高，通过复杂的运算将输入数据转换为固定长度的哈希值，常用于数字证书、文件完整性验证等需要确保数据未被篡改的场景，其计算结果的唯一性和不可逆性使得可以依靠它来判断数据是否被修改。

java 中对象是怎么排序的？Collections.sort () 怎么实现的？

java 中对象排序方式

在 Java 中，对象排序主要有两种方式。一种是让对象所属的类实现java.lang.Comparable接口，在接口中重写compareTo方法，在这个方法里定义对象之间比较大小的规则。例如，对于一个自定义的Person类，有age属性，如果按照年龄对Person对象进行排序，可以在compareTo方法中通过比较age属性的大小来确定两个Person对象的顺序关系，当this.age小于传入对象的age时返回一个负整数，等于时返回 0，大于时返回正整数。这样，当把多个Person对象放入支持排序的集合（如ArrayList）中，调用Collections.sort等排序方法时，就会依据compareTo方法中定义的规则进行排序。

另一种方式是创建一个实现了java.util.Comparator接口的比较器类，重写compare方法，在方法中同样定义对象比较大小的规则。然后在调用排序方法（如Collections.sort）时，将这个比较器对象作为参数传入，这样就可以按照这个比较器定义的规则对对象进行排序，这种方式更加灵活，不需要修改对象所属的类本身，尤其适用于无法修改类源代码或者需要多种不同排序规则的情况，比如对于同一个Person类，既可以按照年龄排序，也可以根据姓名等其他属性创建不同的比较器来实现不同的排序方式。

Collections.sort () 实现原理

Collections.sort方法有多个重载形式，总体来说其实现是基于高效的排序算法，常见的是使用了经过优化的归并排序算法（针对对象数组等情况）。

当传入一个实现了Comparable接口的对象列表时，它会从列表的第一个元素开始，按照对象自身实现的compareTo方法所定义的比较规则，通过不断地比较和交换元素位置（内部类似归并排序的分治、合并过程），逐步将列表中的元素调整为有序状态。例如，在对一个ArrayList中的元素进行排序时，它会先将列表划分成较小的子列表，对这些子列表分别进行排序，然后再合并这些有序的子列表，在合并过程中依据元素间的比较规则正确地放置元素，直到整个列表有序。

如果传入的是一个对象列表以及一个Comparator比较器对象，那么在排序过程中，就会依据这个比较器的compare方法所定义的规则来进行元素间的比较和位置调整，同样通过类似归并排序的一系列操作实现对列表中对象的排序，最终使得列表中的对象按照指定的规则呈现出有序的排列状态，方便后续对有序数据的查找、遍历等操作。

对反射有了解吗（答了动态获取对象，在注解上的应用）

反射是 Java 中一种非常强大且重要的机制，它允许程序在运行时动态地获取类的各种信息，并且可以操作类的对象、方法、字段等元素，而不仅仅局限于编译时所设定的情况。

在动态获取对象方面，通过反射可以根据类的全限定名来加载对应的类，例如使用Class.forName("com.example.MyClass")就能获取到MyClass的Class对象，有了这个Class对象后，就能进一步通过它创建类的实例，比如调用newInstance方法（前提是类有默认的无参构造函数）来实例化对象，这使得在不知道具体类的情况下，仅依据类名就能动态地创建出对象，在一些框架开发、插件化机制等场景中应用广泛，比如在插件系统中，插件可能是后续动态添加进来的不同类，通过反射就可以根据插件配置中的类名来加载并创建插件对应的对象进行使用。

在注解上的应用也很关键，很多框架利用反射和注解配合来实现一些强大的功能。比如在 Java 的持久化框架中，通过自定义注解标记类的字段，注明其与数据库表字段的对应关系等信息，在运行时，框架利用反射获取类中被注解标记的字段，根据注解的内容来进行数据库的映射操作，像知道哪个字段对应数据库表中的哪个列，如何进行数据的读取和存储等。同样，在一些依赖注入框架中，也是通过注解标记需要注入的对象，然后在运行时利用反射查找被注解的字段或者方法，再去实例化并注入相应的对象，实现了代码的解耦和灵活配置，减少了大量手动编写的代码，提高了代码的可维护性和可扩展性。

此外，反射还可以用于动态地调用类的方法，通过获取Class对象后进一步获取Method对象（代表类中的方法），可以指定方法的参数类型等信息，然后调用invoke方法传入具体的对象实例（对于非静态方法）就能在运行时动态地执行这个方法，即使在编译时并不知道具体要调用哪个方法，也能根据运行时的情况灵活操作。对于字段也是如此，可以获取Field对象后，通过set和get方法动态地设置和获取对象中字段的值，突破了常规编程中只能访问可见的、确定的类成员的限制，为开发更灵活、通用的代码提供了有力的手段，不过由于反射涉及较多的运行时检查等操作，相对来说性能会比普通的直接调用方式稍差一些，所以在使用时也要根据具体的场景合理权衡。

Handler 源码说说，从 new Handler（）讲到发消息后回到 handel 里面执行，每一步是怎么样的

当我们创建一个Handler对象，即new Handler()时，在其构造函数内部会进行一系列初始化操作。如果没有显式传入Looper对象，它会默认获取当前线程的Looper，通过Looper.myLooper()方法来获取，若当前线程没有Looper（比如在非主线程且没手动创建Looper的情况下），则会抛出异常，因为Handler必须关联一个Looper才能正常工作。同时，它还会获取与这个Looper对应的MessageQueue，也就是Looper持有的消息队列，后续用于存放要处理的消息。

接着，当我们通过Handler的sendMessage等方法发送消息时（比如sendMessage(Message msg)），实际上是将这个消息添加到了获取到的MessageQueue中，在内部会调用MessageQueue的enqueueMessage方法，这个方法会按照一定的规则（比如根据消息的延迟时间等属性）将消息插入到队列中的合适位置。

而Looper一直在不断地循环，通过Looper.loop()方法实现，在这个循环里，它会不断地调用MessageQueue的next方法从队列中取出消息，一开始如果队列为空，它会阻塞在这里等待有消息到来。当取出一个消息后，Looper会判断消息是否为空等情况，然后调用msg.target.dispatchMessage(msg)来分发消息，这里的msg.target其实就是发送这个消息的Handler对象，所以就会进入到对应的Handler的dispatchMessage方法中。

在Handler的dispatchMessage方法里，它会首先判断是否有设置Callback并且这个Callback的handleMessage方法能处理该消息，如果可以就交给Callback处理；若没有或者Callback不处理该消息，就会判断当前Handler是否重写了handleMessage方法，如果重写了，就会进入到handleMessage方法里执行具体的业务逻辑，至此就完成了从发送消息到在Handler里执行相应处理的整个过程。

sendMessageDelayed () 加了延时发送，然后现在还没到时间，messageQueue 和 looper 会怎么操作？

当使用sendMessageDelayed()方法发送一个带有延迟时间的消息后，Handler内部会将这个消息传递给MessageQueue。MessageQueue在接收到这样的消息时，会根据消息的延迟时长以及当前时间等信息来确定它在队列中的插入位置。

MessageQueue内部的数据结构类似一个按照时间排序的优先级队列，对于延迟消息，它会插入到合适的位置，使得那些应该更早被处理的消息（即延迟时间更短或者已经到时间的消息）排在前面。然后，Looper在不断循环调用MessageQueue的next方法尝试获取下一个要处理的消息时，如果当前取出的消息还没到执行时间（也就是延迟时间未结束），MessageQueue的next方法会阻塞，阻止Looper获取这个未到期的消息继续往下执行，Looper也就处于等待状态，继续循环等待MessageQueue有可执行的消息（即延迟结束或者本身就是无延迟的消息）到来。

在等待过程中，MessageQueue会持续监测时间，随着系统时间的推移，一旦之前延迟的消息到达了设定的执行时间，它会在内部调整队列的状态（比如标记该消息可被取出等），使得下次Looper调用next方法时能够获取到这个消息，然后Looper就会将消息分发给对应的Handler进行处理，按照正常的消息处理流程执行后续的dispatchMessage等操作，从而完成对这个延迟消息的处理。

程序在 looper.prepare () 和 looper.loop () 之间发生了异常会怎么样？

在Looper.prepare()和Looper.loop()之间发生异常时，情况取决于具体的异常处理机制以及应用所处的环境。

首先，Looper.prepare()方法主要是用于创建一个Looper对象并将其与当前线程绑定，为后续的消息循环做准备。如果在这个方法调用之后、Looper.loop()调用之前出现异常，由于此时Looper已经创建好了，但是还没有开始真正进入循环去处理消息，那么后续的消息处理流程自然就无法启动了。

对于线程本身而言，如果没有在代码中显式地进行异常捕获处理，异常会沿着调用栈向上抛出，可能导致线程提前终止执行，并且与这个线程相关的一些操作和资源都无法按照预期进行下去。例如，如果是在一个子线程中进行这样的操作，该子线程原本计划通过Looper来接收和处理一些特定的消息以完成相应的业务逻辑，一旦出现异常，这些业务逻辑就无法执行，相应的消息也无法被处理，同时可能影响到依赖该子线程执行结果的其他部分代码。

从应用整体来看，如果有多个线程存在这样的情况，可能会导致部分功能模块失效，甚至影响整个应用的稳定性。不过，要是在代码中有合适的异常捕获机制，比如使用try-catch块将这段代码包裹起来，就可以在捕获异常后进行相应的处理，比如记录异常信息用于后续分析、尝试重新初始化Looper或者采取其他补救措施来尽量保证业务的正常运行，避免因为这个异常而让整个应用陷入不可控的状态。

ActivityThread 的 main 方法是怎么启动的？

ActivityThread的main方法是整个 Android 应用启动过程中的关键环节，它的启动有着一套特定的流程。

当我们点击手机上的应用图标启动一个 Android 应用时，首先系统的Zygote进程会发挥作用。Zygote进程在启动后会预加载一些系统资源、创建 Java 虚拟机等，为后续快速创建应用进程做好准备。当要启动具体的应用时，Zygote会通过fork机制来创建一个新的子进程，这个子进程就是应用的进程，在创建过程中会继承Zygote进程已经预加载好的很多内容，极大地提高了启动效率。

在新创建的应用进程中，会执行一些初始化操作，然后就会调用ActivityThread类的main方法。在main方法内部，首先会进行一些环境的准备工作，比如设置主线程的相关属性等，接着通过Looper.prepareMainLooper()方法创建一个与主线程关联的Looper，这个Looper是用于处理主线程上的各种消息的，像用户的触摸事件、系统的广播消息等都会通过这个Looper对应的MessageQueue进入到主线程进行处理。

然后，ActivityThread会创建一个ActivityThread的实例（它自身是一个单例模式的类），并通过这个实例启动一些重要的系统组件，比如创建和启动Activity、Service等相关组件的管理流程，同时调用Looper.loop()方法让主线程进入消息循环状态，开始不断地从MessageQueue中获取消息并处理，这样整个应用就正式启动并开始响应各种用户操作和系统事件了，维持着应用的正常运行状态，直到应用被关闭。

对 DNS 协议的理解

DNS（Domain Name System）协议是互联网中极为重要的一个协议，它主要起到将便于人们记忆的域名转换为计算机能够识别的 IP 地址的作用。

在网络通信中，我们通常使用域名（比如www.example.com）来访问网站等网络资源，但计算机在网络中实际是通过 IP 地址来定位和通信的，DNS 协议就是充当了这个中间的 “翻译官” 角色。当我们在浏览器中输入一个域名发起请求时，客户端（比如电脑、手机等设备上的网络应用程序）会首先向本地的 DNS 服务器发送一个 DNS 查询请求，这个本地 DNS 服务器可以是由网络服务提供商配置的，或者是路由器等设备内置的。

本地 DNS 服务器收到请求后，会先查看自己的缓存中是否已经有对应的域名到 IP 地址的映射记录，如果有，就直接将 IP 地址返回给客户端，这样就能快速建立与目标服务器的连接进行后续的通信。若本地 DNS 服务器的缓存中没有该记录，它会向更高级别的 DNS 服务器（比如根 DNS 服务器、顶级域名 DNS 服务器等）依次发起查询请求，通过层层解析域名，最终找到负责该域名解析的权威 DNS 服务器，从这个权威服务器获取到对应的 IP 地址后，再将其返回给客户端，并且本地 DNS 服务器会将这个映射记录缓存起来，方便下次查询使用。

DNS 协议采用了分布式的数据库架构来存储域名和 IP 地址的映射信息，这样可以高效地应对海量的域名解析请求，同时保证了域名系统的可靠性和可扩展性。它使得我们能够方便地通过简单易记的域名去访问各种网络资源，而无需记住复杂的 IP 地址，极大地提升了互联网使用的便利性，并且在整个互联网的信息传递和交互过程中起到了基础性的支撑作用。

一个页面最多显示 8 条 item，用 RecyclerView 的话最多创建几个 View

在使用 RecyclerView 时，其创建 View 的数量并不是固定等于要显示的 item 数量的。RecyclerView 有一套高效的视图复用机制，目的是为了节省内存和提升性能。

一般来说，RecyclerView 会创建比可见 item 数量略多一些的 View，具体数量取决于多种因素。例如，考虑到屏幕滚动等情况，它会预创建和缓存一部分视图，以便在滚动过程中快速复用，避免频繁地重新创建和销毁视图带来的性能损耗。

通常情况下，会创建足够填满屏幕以及额外预留一部分（比如一两屏的量，具体因设备、布局等因素有变化）用于滚动切换时复用的视图数量。假设设备屏幕高度刚好能完整显示 8 条 item，在普通场景下，RecyclerView 可能会创建大概 10 到 15 个左右的 View，这其中包含了当前屏幕显示的 8 个，还有一些缓存起来用于上下滚动时能迅速切换显示的。

而且不同的布局管理器（如 LinearLayoutManager、GridLayoutManager 等）也会对创建 View 的数量产生影响。比如 LinearLayoutManager 在垂直滚动时，主要是按照线性顺序去管理视图复用；而 GridLayoutManager 如果是多列布局，在滚动过程中，复用逻辑会相对复杂些，涉及行列方向的视图复用判断，但总体也是遵循复用原则尽量减少 View 的创建数量，不过具体的创建上限很难确切说就是某个固定值，会随着滚动状态、缓存策略、设备性能等动态变化。

假设一个类 A 的两个非静态方法 m1 和 m2 都用了 synchronized 修饰，现在创建了一个 A 的对象 a，两个线程分别调用 a.m1 () 和 a.m2 ()，可以同时进行吗？在 m1 () 中用了 wait ()，能同时进行吗？在 m1 () 中用了 sleep ()，能同时进行吗？

对于两个线程分别调用 a.m1 () 和 a.m2 () 的情况

当一个类 A 的两个非静态方法 m1 和 m2 都用了 synchronized 修饰，并且创建了一个 A 的对象 a 时，两个线程分别调用 a.m1 () 和 a.m2 () 是不能同时进行的。因为在 Java 中，对于同一个对象的同步方法，它们使用的是对象锁（也就是 this 对象锁，这里就是对象 a 对应的锁）。当一个线程进入了对象 a 的其中一个同步方法（比如进入了 m1 () 方法），就获取了对象 a 的锁，此时另一个线程想要调用对象 a 的另一个同步方法（m2 () 方法），由于需要获取相同的对象锁，就会被阻塞，直到持有锁的线程释放锁，它才能获取锁进入相应的同步方法执行，所以这两个调用不能同时进行。

在 m1 () 中用了 wait () 的情况

如果在 m1 () 方法中调用了 wait () 方法，此时调用 m1 () 的线程会释放对象 a 的锁，进入等待状态，等待其他线程通过调用对象 a 的 notify () 或者 notifyAll () 方法来唤醒它。而另一个线程此时就有机会获取对象 a 的锁，从而进入到 m2 () 方法（前提是它原本就在等待获取锁），所以在这种情况下，另一个线程调用 a.m2 () 是可以进行的，也就是可以实现两个线程的操作在一定程度上的 “同时” 进行，不过是一个线程等待、一个线程执行的状态。

在 m1 () 中用了 sleep () 的情况

当在 m1 () 方法中使用了 sleep () 方法时，调用 m1 () 的线程只是暂停执行一段时间，但它并不会释放对象 a 的锁，所以另一个线程依然无法获取对象 a 的锁去调用 a.m2 () 方法，两个线程的操作依然不能同时进行，调用 a.m2 () 的线程会继续处于阻塞状态，等待调用 m1 () 的线程结束 sleep () 并执行完 m1 () 方法释放锁之后，才有机会获取锁进入 m2 () 方法执行。

一个类中有个成员变量叫 id，现在重写了 equals 方法使得 id 相同的对象会被视为相等，但现在有两个这个类的对象有这相同的 id，他们的 hashcode 不相等，你觉得这样设计合理吗？如果说不合理，你觉得你会如何设计？

这样的设计是不合理的。在 Java 中，根据约定，如果两个对象通过 equals 方法比较的结果是相等的，那么它们的 hashCode 值必须相等，这是遵循 Java 规范的重要原则。

原因在于很多基于哈希的集合类（比如 HashSet、HashMap 等）在工作时，会先通过对象的 hashCode 值来确定对象在存储结构中的大致位置（比如在 HashMap 中确定桶的位置），然后再通过 equals 方法来进一步精确判断对象是否相等。如果存在 equals 方法判断相等但 hashCode 值不同的情况，就会导致在这些集合类中出现逻辑错误。

例如在 HashSet 中，它的设计初衷是不允许存储重复的元素，判断重复是先根据 hashCode 值来快速筛选，如果两个对象的 hashCode 不同，就会认为它们是不同的元素放入集合中，但实际上按照我们重写的 equals 方法，它们是相等的元素，这就违背了 HashSet 的去重功能，会造成数据的不一致以及集合逻辑的混乱。

对于这样的情况，合理的设计应该是在重写 equals 方法的同时，也要重写 hashCode 方法，确保当两个对象根据 equals 方法判断相等时，它们的 hashCode 值是一致的。可以基于对象的关键属性（这里就是 id 属性）来生成 hashCode 值，比如采用常用的公式，像取 id 的某个数值运算结果（如 id 乘以一个质数等简单运算）作为 hashCode 值，保证只要对象的 id 相同，其 hashCode 值也相同，这样就能让对象在参与基于哈希的操作时符合预期的逻辑，保证各种集合类等使用场景的正确性。

请问 Java 中线程同步如何实现

在 Java 中，实现线程同步有多种方式，以下是一些常见的途径：

使用 synchronized 关键字

修饰方法：可以将需要同步的方法用 synchronized 关键字修饰，分为静态方法和非静态方法。对于非静态方法，同步锁是基于对象实例的，也就是调用这个方法的对象本身（this 对象），同一时刻只有一个线程能获取该对象的锁进入这个同步方法执行，其他线程如果尝试调用这个对象的该同步方法，就需要等待锁被释放。例如，在一个有共享资源访问的类中，对修改共享资源的方法用 synchronized 修饰，就能保证在一个线程修改资源时，其他线程无法同时修改。而对于静态方法，同步锁是基于类对象的，不管创建了多少个该类的实例，同一时刻只有一个线程能获取类对象的锁进入静态同步方法执行，因为所有实例共享这个类级别的锁，常用于对类的静态共享资源进行保护。
修饰代码块：通过 synchronized 关键字修饰代码块，可以更加灵活地控制同步范围，指定具体使用哪个对象作为锁。比如在一个方法中，可能只有一部分代码涉及对共享资源的访问和操作，就可以用 synchronized (this) {} 这样的形式（这里以 this 对象作为锁为例），将这部分代码包裹在同步块内，只有获取了对应的锁（这里就是对象的锁）的线程才能进入同步块执行里面的代码，这样可以缩小同步的范围，减少不必要的锁等待时间，提高多线程并发执行的效率，相比直接修饰整个方法更加精准地控制了同步区域。

使用 ReentrantLock 类

这是 Java 中提供的一个可重入锁，相比于 synchronized 关键字，它提供了更灵活的功能。通过创建 ReentrantLock 对象，然后使用 lock () 方法获取锁，在执行完需要同步的代码后，使用 unlock () 方法释放锁，例如：

ReentrantLock lock = new ReentrantLock();
try {
    lock.lock();
    // 这里放置需要同步的代码，比如对共享资源的操作等
} finally {
    lock.unlock();
}

它还支持一些高级特性，比如可以尝试获取锁（tryLock 方法），如果获取不到锁不会一直阻塞，而是可以根据返回值判断是否获取成功，进而采取不同的操作；还能设置公平锁或非公平锁，公平锁会按照线程请求锁的先后顺序来分配锁，非公平锁则不保证这个顺序，在不同的性能和公平性需求场景下可以灵活选择使用。

使用信号量（Semaphore）

信号量可以控制同时访问某个资源的线程数量，通过设定许可数量来实现。例如，创建一个 Semaphore 对象并设置许可数量为 3，表示最多允许 3 个线程同时访问某个共享资源。线程通过 acquire () 方法获取许可，如果许可数量大于 0，线程获取许可后就可以执行相关操作，许可数量减 1；当执行完操作后，通过 release () 方法归还许可，许可数量加 1，让其他线程有机会获取许可去访问资源，常用于控制对有限资源（如数据库连接池中的连接数量等）的并发访问情况，合理分配资源的使用权限，避免资源过度占用和竞争。

使用 CountDownLatch

CountDownLatch 可以让一个或多个线程等待其他线程完成一组操作后再继续执行。比如创建一个 CountDownLatch 对象，设置计数器的值为 5，有 5 个线程分别在执行一些任务，每个线程完成任务后调用 countDown () 方法将计数器减 1，当计数器的值变为 0 时，一直在等待的线程（通过 await () 方法等待）就可以继续执行了，常用于协调多个线程之间的执行顺序，确保某些关键操作都完成后再进行后续的流程，保证多线程协作的正确性和顺序性。

ActivityThread 的作用

ActivityThread 在 Android 应用的运行过程中起着至关重要的作用，它处于整个应用启动和运行的核心环节。

应用启动相关作用

在应用启动阶段，当系统通过Zygote进程fork出应用的进程后，ActivityThread 的main方法就会被调用启动。它首先会进行一系列的初始化操作，比如为主线程创建Looper，这个Looper用于管理主线程的消息循环，后续应用中各种与用户交互相关的事件（像触摸事件、按键事件等）以及系统的广播消息等都会进入到这个主线程的MessageQueue，然后通过Looper进行循环处理，使得应用能够正常响应外界的各种操作和消息。

接着，ActivityThread 会负责创建和启动应用中的关键组件，例如创建Activity、Service等组件实例，并协调它们的启动流程和生命周期管理。对于Activity来说，ActivityThread 会处理其创建、启动、暂停、恢复以及销毁等各个阶段的相关操作，按照系统的要求和规范来确保Activity能正确地在屏幕上显示、与用户交互以及在不同状态间切换，保证整个应用界面呈现和交互的正常运行。

消息处理和线程协调作用

ActivityThread 内部通过Looper不断循环从MessageQueue中获取消息并进行分发处理，它不仅处理来自系统的消息（如系统广播对应的消息、系统配置变更相关的消息等），也处理应用自身业务逻辑产生的消息（比如在某个Activity中通过Handler发送的自定义消息等），通过这种消息处理机制，有效地协调了主线程以及各个组件之间的交互和协作，让应用内不同的功能模块能够在主线程这个统一的环境下有序地工作，避免了不同操作之间的混乱和冲突。

资源管理和应用状态维护作用

它还参与到应用资源的管理中，比如协调应用对系统资源的使用情况，确保各个组件在合理的范围内占用内存、CPU 等资源，避免出现资源过度消耗影响整个系统的性能和稳定性。同时，ActivityThread 会持续维护应用的整体运行状态，在应用运行过程中，根据系统的要求或者用户的操作等因素，及时调整各个组件的状态，像是在内存紧张时，按照一定的策略决定是否销毁某些Activity来释放内存等，保障应用在不同的场景下都能尽可能平稳地运行，维持良好的用户体验。

AMS 的相关知识

AMS（Activity Manager Service）在 Android 系统中扮演着极为关键的角色。

它主要负责管理整个系统中所有应用的 Activity 的生命周期，从 Activity 的创建、启动、暂停、恢复到最终的销毁，都是在 AMS 的协调和管控之下完成的。例如，当用户点击应用图标启动一个 Activity 时，应用进程会向 AMS 发送请求，AMS 会进行一系列的验证和准备工作，像是检查应用是否有相应的权限、系统资源是否足够等，然后协调各个系统组件来完成 Activity 的创建和显示流程，确保 Activity 能正确地出现在屏幕上并与用户进行交互。

同时，AMS 也参与到任务栈的管理中，维护着各个应用不同任务的栈结构，决定了 Activity 在任务栈中的入栈、出栈顺序以及不同任务栈之间的切换逻辑等，以此来保证整个系统中多任务操作的流畅性和合理性。比如在用户按下返回键或者切换应用时，AMS 会依据任务栈的当前状态来决定是销毁当前 Activity 返回上一个 Activity，还是切换到另一个应用对应的任务栈中的某个 Activity。

而且，AMS 还负责处理 Activity 之间的启动模式相关问题，像标准模式、单例模式、栈顶复用模式等不同启动模式下，对 Activity 的创建和复用等操作有着不同的规则，AMS 严格按照这些规则来确保每个 Activity 都按照预期的方式在系统中运行，避免出现多个相同 Activity 实例混乱展示或者不符合业务逻辑的情况，保障了整个 Android 系统应用界面展示和交互的有序性以及资源利用的高效性。

此外，AMS 还与系统的内存管理等方面紧密相关，在系统内存紧张时，它会根据一定的策略来决定哪些处于后台的 Activity 可以被回收，以释放内存资源，使得系统能够在不同的内存负载情况下都尽量维持稳定的运行状态，为用户提供良好的使用体验。

Binder 如何实现一次拷贝

Binder 机制在 Android 系统中用于不同进程间的通信，它能够实现一次拷贝主要基于其独特的内存映射机制。

在传统的进程间通信方式里，比如通过 Socket 等，数据传输往往需要多次拷贝操作。例如，发送方先将数据从用户空间拷贝到内核空间，然后接收方又要从内核空间拷贝到自己的用户空间，这样多次拷贝就会带来较大的性能损耗。

而 Binder 不同，当一个进程要向另一个进程传递数据时，它利用了内存映射技术。首先，Binder 驱动会在内核空间创建一块共享内存区域，这块区域会同时映射到发送方进程的用户空间以及接收方进程的用户空间。对于发送方来说，它可以直接将数据写入到自己对应的这块映射的用户空间内存区域，由于内存映射的存在，这个操作其实相当于直接写入到了内核空间的共享内存中，而无需额外的从用户空间到内核空间的拷贝步骤。

对于接收方，它同样可以通过自己对应的映射区域直接访问到这块共享内存中的数据，就好像数据已经在自己的用户空间一样，省去了从内核空间再拷贝到接收方用户空间的过程，从而实现了只进行一次数据拷贝就能完成进程间的数据传递，大大提高了进程间通信的效率，尤其在 Android 系统中不同组件（如 Activity、Service 等）频繁进行跨进程通信的场景下，这种高效的拷贝方式减少了资源消耗，提升了系统整体的性能表现。

并且，Binder 还通过复杂的协议和驱动层面的管理，确保了数据的安全性、完整性以及不同进程对共享内存访问的正确性，使得各个进程能够在安全可靠的前提下高效地进行数据交互，满足了 Android 系统多进程通信的复杂需求。

智力题：有 2n 个不规则分布的点，找出一个圆，使得 n 个点在圆内，n 个点在圆外

对于这道智力题，可以采用以下一种思路来解决：

首先，我们可以任选两个点作为圆的直径的两个端点来确定一个初始圆，然后统计这个圆内、外的点数情况。如果刚好满足 n 个点在圆内，n 个点在圆外，那这个圆就是我们要找的圆；但大概率初始情况不会这么理想，所以需要进行动态调整。

接下来，我们通过不断移动这个圆来改变其覆盖的点的情况。一种可行的移动方式是选择圆上的一个点固定，然后让另一个端点沿着某个方向移动，每移动一次就重新统计圆内和圆外的点数，看是否逐渐接近目标的各 n 个点的状态。

另外，还可以考虑从所有点中选取三个点来确定一个圆，因为不在同一直线上的三个点可以唯一确定一个圆。遍历所有可能的三个点的组合，对于每一个确定的圆，同样统计其内部和外部的点数情况，不断尝试不同的组合，直到找到满足条件的圆。

不过，由于点数较多，这种遍历所有组合的方式计算量可能会比较大，所以可以结合一些优化策略，比如先对这些点进行大致的区域划分，根据点的分布疏密情况优先尝试在点比较集中的区域选取三个点来确定圆，提高找到符合条件圆的概率，减少不必要的尝试次数。

同时，也可以通过数学计算来预估圆的半径范围等信息，辅助判断哪些圆更有可能满足条件，排除一些明显不符合要求的情况，逐步缩小搜索范围，最终找到那个使得 n 个点在圆内，n 个点在圆外的圆，虽然这个过程可能相对复杂，需要不断地分析和尝试，但通过合理的策略和足够的耐心，是可以解决这个问题的。

时针和分针一天相遇多少次

我们知道时针每小时走一大格，也就是 360°÷12 = 30°，所以时针每分钟走 30°÷60 = 0.5°；分针每 5 分钟走一大格，也就是每分钟走 360°÷60 = 6°。

一天有 24 小时，每小时时针和分针都会相遇一次，但是在 11 点到 1 点之间有点特殊情况需要单独分析。

从 0 点开始，0 点时两针重合算是一次相遇，然后随着时间推移，分针比时针走得快，会不断追赶时针，设经过 x 分钟两针再次相遇，根据时针和分针走过的角度关系可以列出方程：6x - 0.5x = 360（因为分针比时针多走一圈即 360° 时两针相遇），解方程可得 x = 720/11 分钟，也就是大约每过 1 小时 5 分 27 秒多两针会相遇一次。

在 11 点多的时候，两针会在接近 12 点时相遇一次，然后到 12 点时又重合相遇一次，这中间只算一次相遇情况（因为是连续的重合过程，不能重复计算）。

所以在 12 个小时内，时针和分针会相遇 11 次，那么一天 24 小时内，时针和分针相遇的次数就是 11×2 = 22 次。

我们可以想象成时针和分针在表盘上进行一场 “追逐赛”，分针不断地追赶时针，每追上一次就是一次相遇，通过分析它们的速度差异以及表盘的角度特点，就能准确得出一天内相遇的具体次数，而且这种规律在每个 12 小时周期内基本是一致的，只是要注意 11 点到 12 点之间重合情况的特殊处理，避免重复计算导致结果错误。

代码：View 树遍历

在 Android 开发中，对 View 树进行遍历是一项常见操作，常用的遍历方式有深度优先遍历和层次遍历，以下是它们的具体实现及相关应用场景介绍。

深度优先遍历

深度优先遍历又可以细分为先序遍历、中序遍历和后序遍历（类似二叉树遍历概念，但在 View 树中有其特定的表现形式），不过在 View 树中最常用的是先序遍历，其实现思路及代码示例如下：

通常可以从根视图开始，递归地去访问它的子视图，实现代码可能如下（以 Java 语言示例，假设在 Activity 中操作视图树）：

public void preOrderTraversal(View rootView) {
    if (rootView == null) {
        return;
    }
    // 先访问根视图，可以在这里进行相应操作，比如打印视图的相关信息
    System.out.println("正在访问视图：" + rootView.getClass().getSimpleName());
    if (rootView instanceof ViewGroup) {
        ViewGroup viewGroup = (ViewGroup) rootView;
        for (int i = 0; i < viewGroup.getChildCount(); i++) {
            View childView = viewGroup.getChildAt(i);
            preOrderTraversal(childView);
        }
    }
}

在上述代码中，首先判断传入的根视图是否为空，若为空则直接返回。然后对根视图进行操作（这里只是简单打印视图类名示意），接着判断根视图是否是 ViewGroup 类型，若是则说明它有子视图，通过循环获取每个子视图并递归调用preOrderTraversal方法继续遍历子视图，这样就能按照深度优先的先序遍历方式访问整个 View 树中的所有视图了。

深度优先遍历的优势在于方便对每个视图及其子视图进行深度层面的操作，比如在查找特定类型的视图时，从根视图开始递归查找，一旦找到符合条件的就可以停止查找，常用于视图查找、统计视图数量等操作场景。

层次遍历

层次遍历可以借助队列来实现，就像树的层次遍历那样一层一层地访问视图，示例代码如下：

import java.util.LinkedList;
import java.util.Queue;
 
public void levelOrderTraversal(View rootView) {
    if (rootView == null) {
        return;
    }
    Queue<View> viewQueue = new LinkedList<>();
    viewQueue.add(rootView);
    while (!viewQueue.isEmpty()) {
        View currentView = viewQueue.poll();
        // 访问当前视图，可以进行相应操作，比如记录视图信息等
        System.out.println("正在访问视图：" + currentView.getClass().getSimpleName());
        if (currentView instanceof ViewGroup) {
            ViewGroup viewGroup = (ViewGroup) currentView;
            for (int i = 0; i < viewGroup.getChildCount(); i++) {
                View childView = viewGroup.getChildAt(i);
                viewQueue.add(childView);
            }
        }
    }
}

在这个代码中，首先判断根视图是否为空，为空则返回。接着创建一个队列用于存放视图，将根视图加入队列。然后在循环中，只要队列不为空，就取出队首视图进行访问（这里同样是简单打印示意），如果该视图是 ViewGroup 类型，就将它的所有子视图依次加入队列，这样就能保证按照从上到下、从左到右（对于常见的线性布局等情况）的顺序一层一层地遍历整个 View 树了。

层次遍历常用于需要按层处理视图的情况，比如批量设置视图的可见性、对不同层的视图设置不同的动画效果等，能够按照视图在布局中的层次顺序进行统一的操作，使得操作更具逻辑性和条理性，方便对整个视图结构进行整体层面的管理和调整。