专业做生鲜的网站,有专门做预算的网站没,dw建设的网站怎么看,wordpress点击文章404题目来源#xff1a;https://www.nowcoder.com/discuss/525371909735792640 前文
本期是【捞捞面经】系列文章的第 1 期#xff0c;持续更新中…。
《捞捞面经》系列正式开始连载啦#xff0c;据说看了这个系列的朋友都拿到了大厂offer~
欢迎星标订阅#xff0c;持续更新… 题目来源https://www.nowcoder.com/discuss/525371909735792640 前文
本期是【捞捞面经】系列文章的第 1 期持续更新中…。
《捞捞面经》系列正式开始连载啦据说看了这个系列的朋友都拿到了大厂offer~
欢迎星标订阅持续更新中。。。致力打造校招核心面试攻略~原创面试网站https://www.java2top.cn/ 捞捞面经
生产场景下什么时候用 ArrayList 什么时候用 LinkedList
ArrayList 和 LinkedList 都是 Java 中常用的 List 实现但是由于它们内部数据结构的不同所以在不同的场景下我们会选择使用不同的List。
ArrayListArrayList 内部是使用动态数组来存储数据的所以它在随机访问get和set操作时有很好的性能时间复杂度为O(1)。但是在列表中间插入和删除元素时的性能较差因为需要移动元素时间复杂度为O(n)。所以如果你的需求是大量的随机访问操作少量的插入和删除操作那么 ArrayList 是一个好的选择。LinkedListLinkedList 内部是使用双向链表来存储数据的所以它在列表中间插入和删除元素时有很好的性能时间复杂度为 O(1)需要提前获取到节点的引用否则查找节点的时间复杂度为 O(n)。但是在随机访问时的性能较差因为需要从头部或者尾部开始遍历时间复杂度为 O(n)。所以如果你的需求是大量的插入和删除操作少量的随机访问操作那么 LinkedList 是一个好的选择。
总的来说我们需要根据实际的需求和使用场景来选择合适的 List 实现。
创建线程的方式 继承Thread类这是创建线程的最基本方法。我们可以创建一个新的类继承自 Thread 类然后重写其 run() 方法将我们的任务代码写在 run() 方法中。然后创建该类的对象并调用其 start() 方法来启动线程。 实现Runnable接口我们也可以创建一个新的类实现 Runnable 接口然后将我们的任务代码写在 run() 方法中。然后创建该类的对象将其作为参数传递给 Thread 类的构造器创建 Thread 类的对象并调用其 start() 方法来启动线程。 实现Callable接口和FutureTask类Callable 接口与 Runnable 接口类似但是它可以返回一个结果或者抛出一个异常。我们可以创建一个新的类实现 Callable 接口然后将我们的任务代码写在 call() 方法中。 然后创建该类的对象将其作为参数传递给FutureTask 类的构造器创建 FutureTask 类的对象。最后将FutureTask类的对象作为参数传递给 Thread 类的构造器创建Thread 类的对象并调用其 start() 方法来启动线程。 使用线程池Java 提供了线程池 APIExecutor框架我们可以通过 Executors 类的一些静态工厂方法来创建线程池然后调用其 execute() 或 submit() 方法来启动线程。线程池可以有效地管理和控制线程避免大量线程的创建和销毁带来的性能开销。
以上四种方式前两种是最基本的创建线程的方式但是在实际开发中我们通常会选择使用线程池因为它可以提供更好的性能和更易于管理的线程生命周期。
在并发量特别高的情况下是使用 synchronized 还是 ReentrantLock
在并发量特别高的情况下一般推荐使用 ReentrantLock原因如下
更高的性能在Java 1.6之前synchronized 的性能一般比 ReentrantLock 差一些。虽然在 Java 1.6 及之后的版本中synchronized进行了一些优化如偏向锁、轻量级锁等但在高并发情况下ReentrantLock 的性能通常会优于 synchronized。更大的灵活性ReentrantLock 比 synchronized 有更多的功能。例如ReentrantLock 可以实现公平锁和非公平锁synchronized只能实现非公平锁ReentrantLock 提供了一个 Condition 类可以分组唤醒需要唤醒的线程synchronized 要么随机唤醒一个线程要么唤醒所有线程ReentrantLock 提供了 tryLock 方法可以尝试获取锁如果获取不到立即返回不会像synchronized 那样阻塞。更好的可控制性ReentrantLock可以中断等待锁的线程synchronized无法响应中断也可以获取等待锁的线程列表这在调试并发问题时非常有用。
但是虽然 ReentrantLock 在功能上比 synchronized 更强大但也更复杂使用不当容易造成死锁。而 synchronized 由 JVM 直接支持使用更简单不容易出错。所以在并发量不高对性能要求不高的情况下也可以考虑使用 synchronized。
说一下 ConcurrentHashMap 中并发安全的实现
ConcurrentHashMap 在 Java 1.7 和 Java 1.8 中的实现方式有所不同但它们的共同目标都是提供高效的并发更新操作。下面我将分别介绍这两个版本的实现方式。 Java 1.7在Java 1.7中ConcurrentHashMap 内部使用一个 Segment 数组来存储数据。每个Segment 对象包含一个 HashEntry 数组每个 HashEntry 对象就是一个键值对。Segment 对象是可锁定的每个Segment对象都可以看作是一个独立的 HashMap。 在更新数据时只需要锁定相关 Segment 对象而不需要锁定整个HashMap这样就可以实现真正的并发更新。Segment 的数量默认为 16这意味着 ConcurrentHashMap 最多支持 16 个线程的并发更新。 Java 1.8在 Java 1.8 中ConcurrentHashMap 的实现方式进行了改进。它取消了 Segment 数组直接使用 Node 数组来存储数据。每个Node对象就是一个键值对。在更新数据时使用 CAS 操作和 synchronized 来保证并发安全。 具体来说如果更新操作发生在链表的头节点那么使用 CAS 操作如果发生在链表的其他位置或者发生在红黑树节点那么使用synchronized。这样ConcurrentHashMap可以支持更多线程的并发更新。
总的来说ConcurrentHashMap 通过分段锁Java 1.7或 CASsynchronizedJava 1.8的方式实现了高效的并发更新操作从而保证了并发安全
你说高并发下 ReentrantLock 性能比 synchronized 高那为什么 ConcurrentHashMap 在 JDK 1.7 中要用 ReentrantLock而 ConcurrentHashMap 在 JDK 1.8 要用 Synchronized
这是一个很好的问题。首先我们需要明确一点虽然 ReentrantLock 在某些情况下的性能优于synchronized但这并不意味着在所有情况下都是这样。
实际上synchronized 在JDK 1.6 及以后的版本中已经进行了大量的优化例如偏向锁、轻量级锁等使得在竞争不激烈的情况下synchronized 的性能已经非常接近甚至超过 ReentrantLock。
在 JDK 1.7的 ConcurrentHashMap中使用 ReentrantLockSegment是为了实现分段锁的概念即将数据分成多个段每个段独立加锁从而实现真正的并发更新。这种设计在当时是非常先进和高效的。
然而在 JDK 1.8 的 ConcurrentHashMap 中为了进一步提高并发性能引入了更复杂的数据结构如红黑树和更高效的并发控制机制如CAS操作。在这种情况下使用 synchronized 比 ReentrantLock 更加简单和高效。首先synchronized 可以直接与JVM进行交互无需用户手动释放锁减少了出错的可能性。
其次synchronized 在 JDK 1.6及以后的版本中已经进行了大量的优化性能已经非常接近 ReentrantLock。最后synchronized 可以与其他 JVM 特性如偏向锁、轻量级锁、锁消除、锁粗化等更好地配合进一步提高性能。
总的来说选择使用 ReentrantLock 还是 synchronized需要根据具体的需求和使用场景来决定。在 JDK 1.8 的 ConcurrentHashMap中使用 synchronized 是一种更加合理和高效的选择。
有哪些并发安全的实现方式
synchronized关键字这是最基本的并发安全实现方式它可以保证同一时刻最多只有一个线程执行该段代码从而保证了类的实例状态的线程安全。volatile关键字volatile 关键字可以保证变量的可见性和禁止指令重排序但不能保证复合操作的原子性。它通常用于标记状态变量。Lock接口和其实现类例如ReentrantLock、ReentrantReadWriteLock等。相比于synchronizedLock接口提供了更强大的功能例如尝试获取锁、可中断的获取锁以及获取公平锁等。原子类例如 AtomicInteger、AtomicLong、AtomicReference 等。这些类通过 CASCompare and Swap操作实现了原子性更新。并发集合Java 提供了一些线程安全的集合类例如 ConcurrentHashMap、CopyOnWriteArrayList等。ThreadLocal类ThreadLocal 可以为每个线程创建一个单独的变量副本每个线程都只能操作自己的副本从而实现了线程隔离保证了线程安全。Semaphore信号量Semaphore 可以控制同时访问特定资源的线程数量通过acquire()获取一个许可如果没有就等待通过release()释放一个许可。CountDownLatchCountDownLatch允许一个或多个线程等待其他线程完成操作。CyclicBarrierCyclicBarrier 让一组线程到达一个屏障也可以叫同步点时被阻塞直到最后一个线程到达屏障时屏障才会开门所有被阻塞的线程才会继续运行。PhaserPhaser 是 JDK 1.7引入的一个用于解决控制多个线程分阶段共同完成任务的类。
以上就是 Java 中常见的一些并发安全的实现方式。
不用 ThreadLocal 你会想用什么方式存用户信息
如果不使用 ThreadLocal 来存储用户信息我会考虑以下几种方式
参数传递这是最直接的方式将用户信息作为方法的参数传递。这种方式的优点是简单直接不依赖任何特定的技术。缺点是如果调用链很长那么需要在很多方法之间传递用户信息可能会使代码变得复杂。全局变量可以将用户信息存储在全局变量中。但是这种方式需要注意并发控制和内存泄漏问题。如果是Web应用可以考虑将用户信息存储在 Session 或 Cookie 中。数据库或缓存可以将用户信息存储在数据库或缓存中如 Redis。这种方式的优点是可以持久化用户信息适合存储大量的用户信息。缺点是访问数据库或缓存的速度比访问内存慢可能会影响性能。上下文对象可以创建一个上下文对象将用户信息存储在上下文对象中。然后将上下文对象传递给需要使用用户信息的方法。这种方式的优点是可以避免在方法之间传递大量的参数。缺点是需要手动管理上下文对象的生命周期。
以上就是我考虑的几种存储用户信息的方式具体使用哪种方式需要根据实际的需求和场景来决定。
有千万级数据如何判断一个整数是否存在
对于千万级的数据如果要判断一个整数是否存在可以考虑以下几种方法
哈希表哈希表如 Java 中的 HashSet 或 HashMap可以在 O(1) 的时间复杂度内判断一个元素是否存在。但是哈希表需要大量的内存空间来存储数据和哈希表本身。如果内存空间有限那么这可能不是一个好的选择。布隆过滤器布隆过滤器是一种空间效率极高的随机数据结构它利用位数组很简洁地表示一个集合并能判断一个元素是否属于这个集合。它的优点是空间效率和查询时间都远远超过一般的算法缺点是它存在一定的误识别率和删除困难。位图如果整数的范围不大例如都是非负整数那么可以使用位图BitSet来判断一个整数是否存在。位图的每一位代表一个整数如果整数存在那么对应的位就置为 1。位图需要的内存空间远小于哈希表但是如果整数的范围非常大那么位图可能就不适用了。数据库如果数据已经存储在数据库中那么可以直接使用 SQL 查询来判断一个整数是否存在。这种方法的效率取决于数据库的性能和数据的索引情况。二分查找如果数据是有序的那么可以使用二分查找来判断一个整数是否存在。二分查找的时间复杂度是 O(log n)但是它需要数据是有序的。
以上就是判断一个整数是否存在的几种方法具体使用哪种方法需要根据实际的需求和场景来决定。
如何理解布隆过滤器说某个元素存在则大概率在。布隆过滤器说某个元素不在则一定不在
布隆过滤器是一种概率型的数据结构它的主要特点是高效地判断一个元素是否在一个集合中。它的基本原理是通过多个哈希函数将元素映射到一个位数组中。当查询一个元素是否存在时通过同样的哈希函数计算出位数组中的位置如果所有的位置都是1那么就认为元素可能存在如果有任何一个位置是 0那么就认为元素一定不存在。
这里的 可能存在” 和 “一定不存在” 是因为布隆过滤器的特性决定的
当布隆过滤器说某个元素存在时实际上可能会出现误判的情况。因为不同的元素可能会被哈希到位数组的同一位置这就可能出现一个元素实际上不存在但是因为其哈希位置被其他元素占用所以布隆过滤器判断它存在。这就是所谓的“假阳性”。当布隆过滤器说某个元素不存在时那么这个元素一定不存在。因为如果一个元素存在那么它的哈希位置一定会被设置为1。如果布隆过滤器说某个元素不存在那么说明至少有一个哈希位置是 0那么这个元素一定不存在。这就是所谓的“真阴性”。
因此布隆过滤器的一个重要特性就是它可能会误判一个不存在的元素为存在假阳性但是绝不会误判一个存在的元素为不存在真阴性。这就是“布隆过滤器说某个元素存在则大概率在。布隆过滤器说某个元素不在则一定不在”的含义。
千万级数据用布隆过滤器初始化的时候 redis 太慢了有没有什么好方法
对于千万级的数据如果直接使用Redis来初始化布隆过滤器确实可能会比较慢。这是因为Redis的操作都是网络IO操作相比于内存操作网络IO的速度要慢很多。以下是一些可能的优化方法
批量操作Redis支持批量操作可以一次性发送多个命令然后一次性接收所有的结果。这样可以减少网络IO的次数提高效率。管道操作Redis还支持管道操作可以一次性发送多个命令不需要等待上一个命令的结果就可以发送下一个命令。这样可以进一步减少网络IO的次数。多线程或多进程可以使用多线程或多进程来并行初始化布隆过滤器。每个线程或进程负责一部分数据这样可以充分利用多核CPU提高效率。使用更快的存储如果条件允许可以考虑使用更快的存储例如SSD硬盘或者直接在内存中初始化布隆过滤器。预热数据如果数据不经常变动可以考虑预先计算好布隆过滤器的状态然后保存在文件或数据库中。需要使用时直接加载预先计算好的状态这样可以避免实时初始化布隆过滤器。
以上就是一些可能的优化方法具体使用哪种方法需要根据实际的需求和场景来决定。
多线程间如何传值
多线程间传递值主要有以下几种方式
共享内存多个线程可以共享同一个进程的内存空间因此可以通过修改内存中的变量来传递值。但是需要注意的是多个线程同时修改同一个变量可能会导致数据不一致的问题因此通常需要使用锁或其他同步机制来保证数据的一致性。线程局部变量例如 Java 中的 ThreadLocal可以为每个线程创建一个独立的变量副本每个线程只能访问和修改自己的副本不会影响其他线程的副本。通过队列传递可以使用线程安全的队列如 Java 中的 BlockingQueue 来传递值。一个线程将值放入队列另一个线程从队列中取出值。通过管道传递某些编程语言如 Python 支持使用管道Pipe来传递值。一个线程将值写入管道另一个线程从管道中读取值。通过Future和Callable在 Java 中可以使用 Future 和 Callable 来在多线程间传递值。Callable 是一个可以返回值的任务Future 可以用来获取 Callable 任务的返回值。
以上就是多线程间传递值的几种方式具体使用哪种方式需要根据实际的需求和场景来决定。
如何设计登陆黑名单
设计登录黑名单的主要目的是防止恶意用户或者机器人进行暴力破解或者恶意登录。以下是一种可能的设计方案
记录登录失败次数对每个用户或者 IP 地址记录其登录失败的次数。如果在一定时间内登录失败次数超过某个阈值那么就将该用户或者 IP 地址加入黑名单。设置黑名单有效期黑名单不应该永久有效否则可能会误伤正常用户。可以设置一个有效期例如 24 小时。超过有效期后自动将用户或者 IP 地址从黑名单中移除。使用布隆过滤器为了高效地判断一个用户或者 IP 地址是否在黑名单中可以使用布隆过滤器。布隆过滤器可以在近似 O(1) 的时间复杂度内判断一个元素是否存在。黑名单同步如果系统是分布式的那么需要考虑黑名单的同步问题。可以使用消息队列或者Redis等工具来同步黑名单。提供解封接口对于误伤的正常用户应该提供一个解封的接口或者方式。例如可以通过验证邮箱或者手机短信来解封。记录黑名单日志对于被加入黑名单的用户或者 IP 地址应该记录详细的日志包括被加入黑名单的时间原因以及登录失败的详细信息。这对于后期的审计和分析都是非常有帮助的。
以上就是设计登录黑名单的一种可能的方案具体的设计可能还需要根据实际的需求和场景来调整。
