cell

1.依赖 <!-- poi --> < dependency > < groupId > org.apache.poi </ groupId > < artifactId > poi </ artifactId > < version > 4.1.0 </ version > </ dependency > 2. 基本使用 //1. 在内存中创建一个excel文件 工作薄 HSSFWorkbook book = new HSSFWorkbook ( ) ; //2. 通过book创建Sheet HSSFSheet sheet03 = book . createSheet ( "sheet03" ) ; //3. 通过sheet创建row HSSFRow row = sheet03 . createRow ( 0 ) ; //第一行 //4. 通过row 创建 cell HSSFCell cell = row . createCell ( 0 ) ; //第一列 //5. 在cell中存值 cell . setCellValue ( "helloworld~~~" ) ; sheet03 . autoSizeColumn ( 0 ) ; //第一列宽度自适应 // 存储工作薄 book . write ( new File ( "d:\\test\\test.xls" ) ) ;

一、LongAdder简介 JDK1.8时， java.util.concurrent.atomic 包中提供了一个新的原子类： LongAdder 。 根据Oracle官方文档的介绍，LongAdder在高并发的场景下会比它的前辈————AtomicLong 具有更好的性能，代价是消耗更多的内存空间： 那么，问题来了： 为什么要引入 LongAdder ？ AtomicLong 在高并发的场景下有什么问题吗？ 如果低并发环境下， LongAdder 和 AtomicLong 性能差不多，那 LongAdder 是否就可以替代 AtomicLong 了？ 为什么要引入LongAdder？ 我们知道， AtomicLong 是利用了底层的CAS操作来提供并发性的 ，比如 addAndGet 方法： 上述方法调用了 Unsafe 类的 getAndAddLong 方法，该方法是个 native 方法，它的逻辑是采用自旋的方式不断更新目标值，直到更新成功。 在并发量较低的环境下，线程冲突的概率比较小，自旋的次数不会很多。但是，高并发环境下，N个线程同时进行自旋操作，会出现大量失败并不断自旋的情况，此时 AtomicLong 的自旋会成为瓶颈 。 这就是 LongAdder 引入的初衷—— 解决高并发环境下 AtomicLong 的自旋瓶颈问题 。 LongAdder快在哪里？ 既然说到