1. java中 怎么确保一个集合不能被修改

Java 中可以使用 Collections 类的 unmodifiableXXX() 方法来确保一个集合不能被修改。其中，XXX 表示需要被转换的集合类型，如 List、Set、Map 等。这些方法都返回指定集合的不可修改视图。

例如，如果需要确保一个 List 集合不能被修改，可以使用以下方法：

List<String> list = new ArrayList<>();
// 往集合中添加元素List<String> unmodifiableList = Collections.unmodifiableList(list);
// 将 List 转换为不可修改的视图unmodifiableList.add("element"); // 会抛出 UnsupportedOperationException 异常

在上述代码中，将一个 ArrayList 集合转换为了不可修改的 List 视图，并且尝试向该视图中添加新元素，此时会抛出 UnsupportedOperationException 异常。

需要注意的是，虽然通过 unmodifiableXXX() 方法返回的集合视图可以防止对其进行新增、移除、修改等操作，但实际上集合元素本身并没有被修改，因此如果原始集合发生了变化，集合视图也会发生变化。因此，需要确保不会通过其他方式来修改原集合。

2. 队列和栈是什么 有什么区别

队列和栈都是常见的数据结构，其主要区别在于元素的插入和删除顺序不同。

队列（Queue）是一种先进先出（First-In-First-Out，FIFO）的数据结构，类似于排队等待服务。新元素总是被添加到队列的尾部，而最先被添加的元素则总是位于队列的头部，也就是说，在队列中，先进入队列的元素也会先被处理。我们可以通过调用队列的 offer() 方法向队列的尾部添加元素，可以通过 poll() 方法从队列的头部删除元素。

栈（Stack）是一种后进先出（Last-In-First-Out，LIFO）的数据结构，类似于叠罗汉。新元素总是被添加到栈的顶部，而最上面的元素则总是最后一个被处理，也就是说，在栈中，后进入的元素先被处理。我们可以通过调用栈的 push() 方法向栈的顶部添加元素，可以通过 pop() 方法从栈的顶部删除元素。

另外，还有一个明显的区别是队列允许在任何时候插入和删除元素，而栈只能在栈顶进行操作。此外，队列通常有多种实现方式，如线性队列、循环队列和阻塞队列等，每种实现方式都有其特点和适用场景；而栈的实现方式相对单一，大多数情况下只需要使用基本的数组或链表即可。

因此，当需要处理一些按顺序排列的元素集合时，需要先进先出的情况下就可以选择使用队列，如事件、消息等系统；而对于需要依次处理栈顶的情况，就可以使用栈，如表达式求值、函数调用等场景。

3. Java8开始的ConcurrentHashMap为什么舍弃了分段锁

Java8开始的ConcurrentHashMap舍弃了分段锁，主要是为了提高并发性能，这是因为在高并发下使用分段锁会出现一些缺点。

首先，基于分段锁的 ConcurrentHashMap 在处理高并发场景时会出现频繁的竞争，每当有新元素插入到集合中或者需要进行调整时，需要加锁来保证原子性，在竞争激烈的情况下加锁的开销会显得很大，阻碍整个系统的并发度。

其次，分段锁本身也存在一些问题，例如需要维护多个锁对象、容易产生死锁等。虽然 JDK 7 中的 ConcurrentHashMap 引入了 Resize 的方式减少锁的争用，但在极端情况下仍然难以避免锁引起的性能问题。

而在 Java8 中，ConcurrentHashMap 对底层数据结构进行了重构，在实现上使用了 CAS 操作（Compare And Swap，比较并交换）和内存屏障等机制，可以实现更高效的非阻塞并发操作。这种方式在多线程访问时避免了锁的开销，在性能表现上能够更好地支持高并发访问，相对于分段锁提供了更好的性能和可扩展性。

另外，在 Java8 中还引入了红黑树（Red-Black Tree）来代替链表，解决了 JDK 7 中并发度低且插入元素慢的问题，同时也让每个线程拥有尽量少的锁操作。这些改进与优化，都大大提升了 ConcurrentHashMap 的效率和性能表现。

4. ConcurrentHashMap 和 Hashtable有什么区别

ConcurrentHashMap 和 Hashtable 都是线程安全的集合类，它们之间有以下几点区别：

同步方式不同
Hashtable 通过 synchronized 关键字来实现同步，对整个对象进行锁定，因此同一时刻只能有一个线程访问该对象。而 ConcurrentHashMap 则通过分段锁（JDK7及之前版本）或者无锁算法（JDK8及以上版本）来实现同步，不同的线程可以同时访问不同部分的数据，因此并发度相对较高，性能也更好。

数据结构不同
Hashtable 的数据结构是数组加链表，当一个链表中元素过多时，会产生严重的时间复杂度优化问题。ConcurrentHashMap在 JDK8 版本后引入红黑树来解决这个问题。

空值和空键的处理不同
Hashtable 不允许 null 值和 null 键，如果以 null 作为 key 或 value 的话则会抛出 NullPointerException。而 ConcurrentHashMap 允许 null 值和 null 键。

迭代器的弱一致性策略不同
当其他独立线程改变了 ConcurrentHashMap 集合中的某个数值时，迭代器仍然可以继续工作，而对于 Hashtable 则不能并发迭代，因为 iterators 在遍历时要锁定整个表格，所以将导致其他线程的所有访问被阻塞。

ConcurrentHashMap 相对于 Hashtable 具有更好的并发性和可伸缩性，在高并发场景下，使用 ConcurrentHashMap 可以提供更优秀的性能表现。

5. ReadWriteLock和StampeLock

ReadWriteLock和StampeLock都是Java并发包中提供的锁机制，它们旨在优化对于读写的并发操作。

ReadWriteLock
ReadWriteLock 接口定义了一个读/写锁，它可以同时允许多个线程读取共享资源，但只允许一个线程写入共享资源，当进行写锁定时，所有读取线程和其他写线程请求该锁定将被阻塞。与一般的 Lock 实现不同的是，ReadWriteLock 允许多个线程同时访问某个资源，以达到提高读取操作性能的目的，在读多写少的场景下，使用 ReadWriteLock 可以有效减小锁竞争，提高并发效率。

StampedLock
StampedLock 的实现基于乐观锁的思想，也是为了优化读操作执行的速度而设计的一种锁机制。由于读取操作比写操作更快，StampedLock 采用乐观策略，当进行读取操作时，会尝试乐观获取锁，如果成功，则直接返回数据，否则就退化成传统的悲观锁来获取锁。StampedLock 中也有三种模式：写模式、悲观读模式和乐观读模式。StampedLock 支持可重入，并提供了将悲观锁降级为乐观锁的方法。

在读多写少的场景下，使用读写锁（ReadWriteLock）或 StampedLock 可以取得很好的性能提升效果。但需要注意的是，并不是所有的场景都适合使用读写锁或 StampedLock，在存在大量写操作并且这些写操作耗时很长的情况下，这两种锁机制可能会导致读操作被阻塞，进而影响系统的响应时间。