【无标题】

Java中使用的并发工具：

1. Locks：Lock接口及其实现类，提供比synchronized更加灵活的锁，可用于控制代码块的并发访问； 2. Condition：Condition接口及其实现类，可以和Lock配合使用，提供像Object.wait()和Object.notify()一样的线程等待/唤醒机制； 3. Atomic：提供原子操作，包括原子递增、递减、赋值等，能够保证线程安全，无需使用synchronized关键字； 4. Concurrent Collections：Java提供的线程安全的集合类，如ConcurrentHashMap、ConcurrentLinkedQueue等，能够在高并发环境下保证数据安全； 5. Executors：Java提供的线程池框架，提供了方便的线程池配置和管理机制，能够有效地控制并发线程的数量； 6. Semaphore：信号量，用于控制并发线程的访问数量，避免资源竞争问题； 7. CountdownLatch：倒计时锁，用于控制并发线程在某个条件满足后同时执行。

单点登录（Single Sign-On, SSO）是指用户只需要进行一次身份认证，就可以在多个不同的应用系统中使用其身份信息而不需要进行多次认证的过程。其实现原理通常如下： 1. 用户访问一个需要认证的应用系统A，该系统检测到用户未认证，则将用户重定向到认证系统。 2. 认证系统收到用户请求，要求用户提供身份验证信息。 3. 用户输入用户名和密码，提交给认证系统。 4. 认证系统验证用户提供的身份信息，并将一个加密令牌（即Ticket）返回给用户的浏览器。 5. 用户浏览器继续访问应用系统A，该系统拦截请求并将用户浏览器中的Ticket发送到认证服务器进行验证。 6. 认证系统检查Ticket是否有效，如果有效，则向应用系统A发出信任令牌（即Token）。 7. 应用系统A验证Token是否有效，如果有效，则将用户视为已认证用户并允许其访问应用系统A。 8. 用户从应用系统A跳转到应用系统B，应用系统B检测到用户未认证，重定向用户到认证系统。 9. 用户的浏览器发送Ticket到认证系统，如果Ticket仍然有效，则认证系统将Token返回给用户浏览器，用户可以使用该Token在应用系统B中访问资源。

Java提供了垃圾回收机制来避免内存泄漏。垃圾回收机制可以自动检测和清理不再被使用的内存空间，从而避免了内存泄漏的情况。 但是，Java中的垃圾回收机制并不能保证100%避免内存泄漏的出现，开发人员也需要注意代码中可能引起内存泄漏的地方。下面介绍几种可能导致内存泄漏的情况以及如何避免它们： 1. 长生命周期对象持有大内存对象：如果长生命周期的对象持有一个大对象的引用，即使这个对象不再被使用，也无法被垃圾回收机制回收。解决这个问题的方案是在长生命周期的对象中使用弱引用或软引用来持有大对象的引用，从而在内存压力过大的时候允许被回收。 2. 集合类对象未清空：集合类对象在Java中常常用于存储大量的数据，如果在操作集合类对象之前未调用clear()方法将对象清空，那么对象的引用和数据将一直保存在内存中，无法被垃圾回收。需要开发人员在使用集合类对象时及时清空对象。 3. 使用ThreadLocal、JNDI和connection对象的忘记关闭：ThreadLocal对象存储在每个线程的本地内存中，不会被垃圾回收清除，因此需要注意及时清空；JNDI和connection对象需要显式地调用close()方法来释放资源。 4. 匿名内部类的使用：匿名内部类的对象生命周期与外部对象相同，如果外部对象存在较长时间而匿名内部类持有大量数据，那么内存可能就无法被回收。解决这个问题需要在使用匿名内部类对象时尽量减少其引用大量数据。 总之，Java中的垃圾回收机制只是减少了内存泄漏的可能性，并不能完全避免。开发人员需要注意代码中可能出现的内存泄漏问题，及时调试并解决这些问题，从而提高系统的性能和可用性。

New一个对象的时候，一共发生了哪些事

在Java中，当我们使用new关键字创建一个对象时，主要会涉及以下几个步骤： 1. 分配内存空间：计算所需内存大小，从堆中分配一块足够的内存，用来存储对象的各个属性。 2. 初始化对象：将对象的所有属性设置为默认值，比如数值类型为0，布尔类型为false，引用类型为null。 3. 调用构造方法：根据构造函数的参数列表，将参数传递给构造方法，以初始化对象的属性。 4. 返回对象的引用：将对象的地址返回给调用者，完成对象的创建过程。 除此之外，可能还会涉及到一些其他操作，比如： 1. 类加载：如果该类还没有被加载，则需要先进行类加载。类加载过程包括加载、验证、准备、解析和初始化等步骤。 2. 父类构造方法的调用：如果该类有父类，则需要首先调用父类的构造方法。 3. 对象的 finalizer 方法：如果对象在创建后被标记为 finalizable，则在对象被回收前，会将其 finalizer 方法加入到 Finalizer 队列中。 总之，在创建对象的过程中，Java 虚拟机会进行多个步骤，最终生成可以供应用程序使用的 Java 对象。

引入 Redis 和 MQ 解决什么问题，是如何达到高可用的

Redis和MQ（Message Queue）都是常见的分布式系统，它们提供的功能有助于应对一些常见的高可用性问题。 Redis是一个基于内存的键值存储系统，可以用于缓存、数据存储等场景。引入Redis可以解决以下问题： 1. 提供快速的读写性能：Redis将所有数据都存储在内存中，避免了磁盘 I/O 的开销，因此能够提供快速的读写性能。 2. 高可靠性：Redis支持主从复制和集群模式，可以有效地保证系统的可靠性和可用性。 3. 提高系统的可扩展性：由于Redis的内存存储特性，可以将其作为缓存的代替方案，提高系统的可扩展性。 MQ是一种消息传递机制，可以用于实现异步消息传递和解耦。它的引入可以解决以下问题： 1. 提高系统的可伸缩性：通过使用消息队列，可以将系统拆分成多个独立的子系统，从而提高系统的可伸缩性。 2. 解耦：通过消息队列，不同的系统可以通过消息进行通信，从而实现解耦，避免了系统之间的耦合度。 3. 提高系统的可靠性：通过消息队列，可以保证消息的可靠传递，即使在系统出现问题的情况下，消息仍然可以得到正确地处理。 要达到高可用性，可以通过以下方式： 1. 配置主从复制：Redis可以通过配置主从复制来实现数据的备份和高可用。当主节点出现故障时，从节点会自动接替主节点的请求，从而避免了单点故障。 2. 配置集群模式：Redis可以通过配置集群模式来实现数据的分散存储和高可用。当某个节点出现故障时，集群可以自动将数据重新分配到其他节点上，从而保证系统的可用性。 3. 配置多机部署：MQ可以在多台服务器上进行部署，从而实现负载均衡和高可用性。当某台服务器出现故障时，其他服务器可以接替其工作，从而保证系统的可用性。

MQ可以通过消息队列的方式实现解耦、异步和削峰，从而提高系统的可靠性和可用性。 解耦：在两个或者多个系统之间，可能需要进行数据的交互和通信，如果这些系统之间直接进行通信，那么系统之间的耦合度就会很高，一旦其中一个系统出现问题，就会产生连锁反应。而通过引入MQ，可以通过消息队列实现解耦，不同的系统之间通过消息进行通信，避免了直接的系统之间的耦合。 异步：MQ也可以实现异步的消息传递，例如：某个系统需要调用异步接口进行数据处理，在异步请求结束处理之前，系统的运行并不需要等待异步请求的返回结果，而是直接将请求交给MQ进行处理，从而实现异步的系统运行。 削峰：在高并发的系统中，可能会因为请求激增而产生系统瘫痪的情况，而通过MQ实现消息队列的方式，可以将请求以队列的方式进行排队，从而避免了瞬时的请求高峰对系统的影响。 总之，MQ通过异步、解耦和削峰的方式，可以提高系统的可靠性和可用性，减少系统之间的耦合，帮助系统实现更好的可扩展性。

Redis是一种高性能的内存数据库系统，主要用于存储一些经常需要被访问的数据，例如页面缓存、热点数据、消息队列、计数器、排行榜等等。 具体来说，Redis可用来存储： 1. 缓存数据：Redis最常见的应用场景是作为缓存数据的存储，在高访问量的应用中，可以把常用的数据存放在Redis中，减轻数据库的压力，提高数据访问的速度。 2. 用户 session 数据：Redis还可以用于存储用户的 session 数据，可以轻松地实现分布式环境下session的共享和管理，提高应用的安全性和可扩展性。 3. 消息队列：Redis提供了List、PubSub等数据结构，可以很方便地实现消息队列的功能，用于处理异步任务、分发任务、日志处理等。 4. 计数器：Redis提供了incr、decr命令，可以精简地实现计数器，常常用于对访问量、投票数、商品销量等数据的计数。 5. 排行榜：Redis支持sorted set，可以轻松实现各类排行榜（例如App Store中的畅销排行榜）。

MQ还提供了多种异步处理功能： 1. 异步处理：消息队列本身就是一种异步处理机制，可以将消息放入队列中进行异步处理，从而提高系统的性能和响应速度。 2. 订阅发布：MQ通常支持订阅发布功能，发布者发布消息到队列，订阅者从队列中获取消息，实现了事件驱动的编程模型。 3. 消息确认：MQ保证消息的可靠性传递，生产者发送消息到队列的同时，可以设置消息确认，确保消息被正确处理。 4. 事务与批量处理：MQ支持事务和批量处理，可以保证消息的完整性和数据的一致性，将多个消息合并处理，从而提高处理效率。

双写一致性是指当数据系统中有多个副本时，每个副本都要保证数据写入的一致性，保证数据的正确性和可靠性。在实际应用场景中，有很多需要保证双写一致性的场景，比如金融领域的交易系统，互联网领域的用户数据系统等。 为了保证双写一致性，可以采用以下方案： 1. 主备同步：即将主数据写入的任务交给主节点，然后主节点将数据同步到备份节点中，确保主节点和备份节点中的数据保持一致。这种方式需要解决主节点宕机或者主节点写数据不成功的情况。 2. 数据库复制：即将写入的数据同步复制到多个节点中，以保证数据在多节点中的一致性。这种方式可以提高系统的扩展性和可靠性，但是需要解决可读性和可写性的问题。 3. Paxos算法：Paxos算法是一种基于投票决议的一致性协议，可以保证数据系统的数据同步和提交一致性。在Paxos算法中，存在一个Master节点，它通过多次投票决定数据的写入操作。 4. 一致性哈希算法：一致性哈希算法是一种在分布式系统中保证数据分布一致性的算法。它将数据分散到多个节点中，以保证数据的可靠性和容错性。 在实际应用中，需要根据实际场景选取合适的双写一致性方案，以保证系统的可靠性和一致性。

幂等性是指重复执行同样的操作所产生的结果是一致的。在分布式系统的消息队列(MQ)中，幂等性就是指同一条消息被消费多次后，结果仍然是一致的。 为了保证MQ的幂等性，可以采用以下几个方案： 1. 消费端维护幂等性：消费者在消费消息时需要先判断该消息是否已经被消费过，如果已经被消费过，则不进行重复消费。具体实现方式可以是在对应的业务数据表中维护已经消费过的消息ID，或者使用分布式锁和缓存等手段确保幂等性。 2. 消息去重：生产者在发送消息时，以消息ID作为关键字进行去重，保证同一个消息只会被发送一次。可以在消息中加入唯一的ID或者使用哈希算法来去重。 3. 设置消息重试机制：如果因为网络问题或其他原因导致消息消费失败，可以采取消息重发的机制，设置一定的时间间隔，让消费端重新尝试消费该消息。 4. 引入分布式事务：采用分布式事务机制，在消息发送和消费的过程中引入分布式事务保证消息的可靠性、一致性和幂等性。 综上，保证MQ的幂等性需要综合考虑消息的发送和消费两个端，通过具体的方案来保证消息一致性、可靠性和幂等性。

当MQ消息消费失败时，会有两种情况，一种是返回NACK，另一种是抛出异常。在消费失败的情况下，MQ的默认行为是将消息返回给队列或者进行重试，如果一直不成功，这些消费失败的消息就会积压在MQ队列中。 为了避免MQ消息一直积压，需要采取一下措施： 1. 设置消息重试次数及时间间隔: 在消息消费失败的情况下，可以使用消息重试机制。可以根据实际情况设置重试次数及重试的时间间隔，如果消费者在一定时间内无法重新消费该消息，则将该消息移动到死信队列，避免消息永久积压。 2. 设置死信队列: 是处理重试多次后仍无法被处理的消息的一种方法。当某个消息已经被消费多次但都失败了，将会被发送到死信队列，然后在死信队列中重新消费，从而解决消息一直积压问题。 3. 监控中心告警及时处理: 对MQ进行监控，当发现消息积压的情况时，及时告警并人工处理，保持MQ的正常运行状态。 总之，对于MQ中消费异常的消息需要及时处理，否则将会导致MQ队列积压，进而影响MQ的性能和稳定性。停止消费、重试、设置死信队列等措施可以帮助解决MQ消息处理中出现的问题。

在水平分表中，我们将一个大表水平划分为多个小表，每个小表存储同一类型的数据，从而减少单表的数据量和单表的读写负担。水平分表要实现需要以下几个步骤： 1. 定义表结构：定义需要进行水平分表的表结构，包括表名、索引、字段、数据类型等。 2. 设计分表规则：根据业务需求，选择合适的分表规则，如按时间、按地区、按产品等，以保证数据放置的合理性和高效性。 3. 创建分表：根据分表规则，创建多个子表，并按照规则将数据分散到各个子表中。 4. 分配数据：将原始表的数据按照分表规则进行划分，将每条数据都分配到相应的子表中。 5. 维护分表：在使用过程中，需要对分表进行维护和管理，如备份和恢复、数据迁移、整合等。 6. 修改应用程序：在应用程序中，需要进行相应的数据查询和处理逻辑修改，以便正确地访问各个子表。 水平分表需要特别注意的是，分表所带来的复杂性及分布式系统的一致性问题，以及对分布式事务的支持问题等，需要在设计和实现中综合考虑。

事务隔离级别是数据库的一个属性，用来控制多个事务的并发访问对数据库的影响。常见的事务隔离级别有 READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ 和 SERIALIZABLE。 MySQL 默认的事务隔离级别是 REPEATABLE READ。这个隔离级别可以保证在同一事务内多次读取同一个数据得到相同的结果，但可能会出现幻读的现象。 在 MySQL 中，可以通过 SET TRANSACTION ISOLATION LEVEL 命令来设置当前会话的事务隔离级别。例如，可以使用以下命令将当前会话的事务隔离级别设置为 READ COMMITTED： ``` SET TRANSACTION ISOLATION LEVEL READ COMMITTED; ``` 这个命令将在当前会话中的所有事务中使用 READ COMMITTED 隔离级别。需要注意的是，这个设置只对当前会话有效，不会影响其他会话的事务隔离级别。 可以使用 SHOW VARIABLES LIKE 'tx_isolation'; 命令来查看当前系统设置的事务隔离级别。

TCP 协议进行四次挥手的主要原因是，TCP 在建立连接时使用三次握手确保了双方可以互相通信，但在关闭连接时，仅使用三次挥手可能会导致某些情况下出现数据传输不完整的问题。 考虑如下情景：当一端向另一端发送 FIN 报文通知对方要关闭连接时，此时只进行三次挥手，第三次挥手的 ACK 报文也有可能因为某些原因没有到达，导致主动关闭连接的一方一直等待对方的确认报文，而对方并没有发送该报文，也就是连接一直处于半关闭状态，占用资源，无法释放，直到超时或者重新建立连接才能解决问题。为了避免这种情况发生，TCP 进行四次挥手，在确认自己接收到对方的 FIN 报文后，也向对方发送一个 FIN 报文，从而让对方再次确认自己收到了关闭的请求，确保数据传输的完整性。 四次挥手的过程可以描述为： 1. 主动关闭连接的一方发送一个 FIN 报文，表示自己已经没有数据要发送了。 2. 另一端接收到 FIN 报文后，发送一个 ACK 报文进行确认。 3. 另一端完成所有数据的传输后，也发送一个 FIN 报文表示自己也没有数据要发送了。 4. 主动关闭连接的一方接收到 FIN 报文后，再发送一个 ACK 报文进行确认，此时连接关闭。 通过四次挥手，TCP 协议可以完整地进行连接的关闭，确保数据的完整性和可靠性。

HTTPS 是指建立在 SSL/TLS 协议基础上的一种安全通信协议，用于在互联网上保护客户端和服务端之间数据的传输安全和私密性。HTTPS 常用于涉及敏感信息交换的网站，如在线支付、个人信息、账户登录等。 HTTPS 原理： HTTPS 基于公私钥加密算法进行加密，客户端与服务端之间的通信必须先建立 SSL/TLS 加密连接，具体过程如下： 1. 客户端向服务器发送 HTTPS 请求。 2. 服务端向客户端返回公钥证书。 3. 客户端验证证书是否合法，如证书无效则连接终止；否则客户端生成一个随机数，然后使用服务器公钥进行加密，发送加密后的随机数和其他信息给服务端。 4. 服务端使用自己的私钥进行解密，得到客户端发送的随机数，然后使用此随机数作为对称密钥用于下一步的通信加密过程。 5. 服务端向客户端返回加密后的通信密钥和其他信息。 6. 客户端使用随机数生成对称密钥，然后使用服务端返回的密钥对称加密，并向服务端发送加密后的数据。 7. 服务端使用对称密钥进行解密，得到传输的明文数据。 8. 之后所有的数据传输均使用对称密钥进行加密解密，保证通信的安全。

Spring AOP 是 Spring 框架的一个模块，提供面向切面编程（AOP）的支持。AOP 是一种编程习惯，采用 AOP 可以增加代码的模块化程度，使程序的业务逻辑和横向关注点解耦，增加程序的可维护性。 Spring AOP 的应用场景： 1. 日志记录：在系统的各个模块的开始和结束处记录日志信息，便于后期的系统监控和排查问题。 2. 安全验证：通过 AOP 可以在关键方法执行前进行用户权限校验，保证系统的安全性。 3. 性能监控：在关键的业务方法执行时进行性能监控，获取方法的执行耗时，以便系统的优化。 4. 事务处理：在业务方法执行前后提交或回滚事务，保证数据的正确性和一致性。 我的使用经历： 我曾在一个 Java Web 项目中使用过 Spring AOP，主要用于记录系统的操作日志。我们定义了一个切点，对系统的所有 service 方法进行拦截，记录方法的执行时间、参数和返回值等信息，并保存到数据库中。这样，我们可以在后期分析排查问题时，快速找到问题出现的可能原因。使用 Spring AOP，我们把系统的业务逻辑和日志记录分离开来，提高了程序的可维护性和可扩展性。

Redis各种实际使用中可能发生的情况及处理策略，提了三个问题，包括并发、批量删改、回滚三大方面

Redis 是一种内存数据库，它的快速读写能力和丰富的数据结构类型使得其在实际应用中得到广泛应用。在使用 Redis 时，可能会遇到以下情况及处理策略： 1. 并发问题 并发是指多个请求同时对 Redis 进行读写操作，可能会导致数据不一致或者数据丢失的情况。处理策略包括： - 使用 Redis 事务保证多个操作的原子性，从而避免了多个操作之间的竞争。 - 使用 Redis 的分布式锁机制，在执行操作前加锁，结束后释放锁，确保每次只有一个请求能够对 Redis 进行操作。 2. 批量删改问题 在对 Redis 进行批量删改时（例如：批量删除某个 key），可能会因为数据量过大或者操作没有优化导致 Redis 崩溃或者出现性能问题。处理策略包括： - 优化操作，减少批量操作的数据量，尽可能采用更为细致的操作方法。 - 使用 Redis 的 pipeline，可以将多个命令一次性发送给 Redis 服务器，减少了网络传输时间和服务器的响应时间。 3. 回滚问题 在 Redis 中没有提供回滚的机制，一旦出现误操作，数据可能会不可逆转。处理策略包括： - 定期备份数据，每次误操作后可以及时进行数据还原。 - 在进行重要操作时，先备份数据，避免出现严重误操作导致数据损失的情况。 - 在进行数据的更新操作时，使用 Redis 的 setex 命令设置过期时间，这样即使数据有误，也可以在过期时间内进行恢复。

ElasticSearch支持多种类型的搜索，包括全文搜索、短语搜索、前缀搜索、通配符搜索、范围搜索、模糊搜索、聚合搜索等。 实现搜索功能的大致过程如下： 1. 创建索引：使用ElasticSearch提供的API创建索引，并确定索引的mapping（字段类型）和setting（配置参数）。 2. 插入文档：向索引中插入文档（数据），文档是以JSON格式存储的。 3. 动态更新文档：在需要更新文档时，可以使用update API进行动态更新，而不是重新插入一份文档。 4. 删除文档：使用delete API删除不再需要的文档。 5. 发起搜索请求：通过使用ElasticSearch提供的搜索API发起搜索请求，指定搜索条件以及搜索结果的返回格式。 6. 解析搜索结果：收到搜索结果后，进行解析、处理，并根据业务需要进行展示。 在发起搜索请求时，可以指定多个搜索条件和排序方式，其中搜索条件可以包括“term”（精确查询）、“match”（模糊查询）、“range”（范围查询）等。ElasticSearch还支持基于“bool”（逻辑运算）和“filter”（过滤器）等方式进行搜索，同时可以在搜索条件中配置权重（boost）以加强搜索结果的相关性。 为了提高搜索性能，ElasticSearch支持多种优化方式，包括负载均衡、分片副本、索引别名、缓存等。同时，还可以通过ElasticSeach提供的监控和诊断工具定位搜索问题并进行优化。

对EalsticSearch底层分词的原理，分词流程

对于ElasticSearch底层分词的原理，可以简单概括为以下几个步骤： 1. 分析器（Analyzer）的选择：在建立索引时，针对每个字段选择合适的分析器。分析器将文本数据进行分词，并进行一些预处理（如小写转换、去掉停用词、同义词转换等）。 2. 输入分词器（Tokenizer）：分析器先使用输入分词器进行小块切分，得到初始的单词流（Token Stream）。 3. 过滤器（Token Filter）：将一个初始单词流传递给一系列的过滤器，进行进一步的处理。过滤器可以移除指定的单词（停用词）、进行小写转换、提取关键词等等。通过插入不同的过滤器，可以实现不同的分词需求。 4. 输出：最终得到输出的单词流，标准化并存储。单词组成的流供查询时使用。 以中文文本为例，Elasticsearch内置了ik分词器进行中文分词。在使用ik分词器时，可以通过配置实现词库扩展、停用词过滤等功能。ik分词器也有两个组成部分：输入分词器（Tokenizer）和过滤器（Token Filter）。具体分词流程如下： 1. 输入分词器（tokenizer）按照一定的规则将文本切割成一个个词汇。 2. 词汇通过过滤器（token filter）进行处理，如去重、用户自定义停用词过滤、同义词转义等。 3. 处理完成后，生成最终的分词结果，并存储为倒排索引供搜索使用。 总体来讲，Elasticsearch的分词器不仅支持多种语言，而且可以动态添加或修改，从而满足不同的需求。分词器的优化也可以从瓶颈的位置入手，比如配置缓存可以大幅提升性能。