今天学习下ArrayList的源代码，不同于其他人写的博客，很多都是翻译源代码中的注释，然后直接贴到文章中去。小编打算换一种书写风格，带着问题看源码可能收获会更大，本文将围绕着下面几个问题展开讨论。 一、问题产生 1、为什么ArrayList集合中存储元素的容器声明为transient Object[] elementData;？ 2、既然ArrayList可以自动扩容，那么它的扩容机制是怎样实现的？ 3、调用ArrayList的iterator()返回的迭代器是怎样的？ 4、采用ArrayList的迭代器遍历集合时，对集合执行相关修改操作时为什么会抛出ConcurrentModificationException,我们该如何避免？ 5、当集合扩容或者克隆时免不了对集合进行拷贝操作，那么ArrayList的数组拷贝是怎么实现的？ 6、ArrayList中的序列化机制 小编对ArrayList源码大概浏览了之后，总结出以上几个问题，带着这些问题，让我们一起翻开源码解决吧！ 二、问题解答1、为什么ArrayList集合中存储元素的容器声明为transient Object[] eleme ...

也许大家对这个问题都不陌生，实际装过系统用过电脑的朋友可能都有这样的经历：自己电脑配的是4G的内存条，可是装完系统之后发现电脑上显示的只有3.2G左右可用内存，其它的内存跑到哪去了？网上也有很多朋友给出了一些解释，大部分我觉得都没有解释得很清楚，今天我们就来看一下其中的具体缘由。 在此之前先来了解一些计算机系统结构和PC硬件方面的一些知识。 总线结构和主板的构成　　说起总线大家肯定不陌生，而且大家平时肯定跟它打过交道，我们在用U盘拷贝数据的时候先要把U盘通过USB接口与电脑相连才能拷贝。USB接口实际上就是一种总线，一般称这种总线为USB总线（也叫做通用串行总线）。在很久之前是没有USB总线的，那个时候每个外设各自采用自己的接口标准，举个最简单的例子：鼠标生产厂商采用鼠标特有的接口，键盘生产厂商用键盘特有的接口，这样一来的话，PC机上就必须提供很多接口，这样一来增加了硬件设计难度和成本，直到后来USB接口的出现，它统一了很多外设接口的标准，不仅使得用户可以很方便地连接一些外设，更增强了PC的可扩展性。所以现在大家看到的鼠标、键盘、U盘、打印机等等这些外设都可以直接通过USB接口直接插到 ...

堆外内存的优势在于IO操作，相比堆内存可以减少一次copy和gc的次数。下面通过源码去了解堆外内存的分配和回收。一般分配堆外内存通过ByteBuffer allocateDirect(int capacity)方法，其内部是通过如下构造函数来实现。 12345678910111213141516171819202122DirectByteBuffer(int cap) { super(-1, 0, cap, cap);// mark, pos, lim, cap boolean pa = VM.isDirectMemoryPageAligned(); int ps = Bits.pageSize(); long size = Math.max(1L, (long)cap + (pa ? ps : 0)); Bits.reserveMemory(size, cap); long base = 0; try { base = unsafe.allocateMemory(size); ...

Feign简介​ 在上一篇文章中分析了Eureka的注册、续约、服务剔除、服务自我保护等机制，地址在https://blog.csdn.net/lgq2626/article/details/80288992 。这篇分析SpringCloud的feign。SpringCloud微服务项目之间调用是通过httprest请求来进行服务调用的，之前我们会用到HttpClient等工具来进行服务请求，Spring对这种请求进行了处理，封装成了可声明式的web客户端，使得编写web客户端更容易，feign还支持可插拔的编码器和解码器，Spring在用的时候增加了对@requestMapping的处理，同时，SpringCloud还对feign集成了注册中心（eureka）和客户端负载均衡（ribbon），使得我们拥有一个客户端负载均衡的web请求客户端。 Feign在项目中的配置和使用​ 在Springcloud中使用feign的时候，需要在配置类中加入一个@EnableFeignClients注解。代码如下： 12345678@SpringBootApplication ...

前文已经讲过，CMS是老年代垃圾收集器，在收集过程中可以与用户线程并发操作。它可以与Serial收集器和Parallel New收集器搭配使用。CMS牺牲了系统的吞吐量来追求收集速度，适合追求垃圾收集速度的服务器上。 CMS相关参数 参数 类型 默认值 作用 -XX:+UseConcMarkSweepGC boolean false 老年代采用CMS收集器收集 –XX:ParallelGCThreads=n int (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8) 老年代采用CMS收集器收集 -XX:CMSInitiatingOccupancyFraction int 92 年代堆空间的使用率。比如value=75意味着第一次CMS垃圾收集会在老年代被占用75%时被触发。 -XX：+UseCMSInitiatingOccupancyOnly boolean false 只用设定的回收阈值(上面指定的70%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整 触发条件周期性GC由后台线程ConcurrentMa ...

前言线程池ThreadPoolExecutor在运行的过程中，业务并发量变动，需要不停服务调整线程池的线程数，ThreadPoolExecutor支持动态调整corePoolSize与maximumPoolSize的值。 示例demo123456789101112131415161718192021222324252627282930313233343536public class ThreadChangeTest { public static void main(String[] args) throws InterruptedException { ThreadPoolExecutor executor = new ThreadPoolExecutor(3, 10, 10l, TimeUnit.SECONDS, new LinkedBlockingQueue<>(10)); int count = 0; while (tru ...

在数据仓库的建设中，一般都会围绕着星型模型和雪花模型来设计表关系或者结构。下面我们先来理解这两种模型的概念。 星型模型 ​ 星型模是一种多维的数据关系，它由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。 雪花模型 ​ 当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 “层次 “ 区域，这些被分解的表都连接到主维度表而不是事实表。雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模 ...

聚集（clustered）索引，也叫聚簇索引定义：数据行的物理顺序与列值（一般是主键的那一列）的逻辑顺序相同，一个表中只能拥有一个聚集索引。 注：第一列的地址表示该行数据在磁盘中的物理地址，后面三列才是我们SQL里面用的表里的列，其中id是主键，建立了聚集索引。 结合上面的表格就可以理解这句话了吧：数据行的物理顺序与列值的顺序相同，如果我们查询id比较靠后的数据，那么这行数据的地址在磁盘中的物理地址也会比较靠后。而且由于物理排列方式与聚集索引的顺序相同，所以也就只能建立一个聚集索引了。 从上图可以看出聚集索引的好处了，索引的叶子节点就是对应的数据节点（MySQL的MyISAM除外，此存储引擎的聚集索引和非聚集索引只多了个唯一约束，其他没什么区别），可以直接获取到对应的全部列的数据，而非聚集索引在索引没有覆盖到对应的列的时候需要进行二次查询，后面会详细讲。因此在查询方面，聚集索引的速度往往会更占优势。 创建聚集索引如果不创建索引，系统会自动创建一个隐含列作为表的聚集索引。 创建表的时候指定主键（注意：SQL Sever默认主键为聚集索引，也可以指定为非聚集索引，而MySQL里主键就 ...

前提近段时间，业务系统架构基本完备，数据层面的建设比较薄弱，因为笔者目前工作重心在于搭建一个小型的数据平台。优先级比较高的一个任务就是需要近实时同步业务系统的数据（包括保存、更新或者软删除）到一个另一个数据源，持久化之前需要清洗数据并且构建一个相对合理的便于后续业务数据统计、标签系统构建等扩展功能的数据模型。基于当前团队的资源和能力，优先调研了Alibaba开源中间件Canal的使用。 这篇文章简单介绍一下如何快速地搭建一套Canal相关的组件。 关于Canal简介下面的简介和下一节的原理均来自于Canal项目的README： Canal[kə'næl]，译意为水道/管道/沟渠，主要用途是基于MySQL数据库增量日志解析，提供增量数据订阅和消费。早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务trigger获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。 基于日志增量订阅和消费的业务包括： 数据库镜像 数据库实时备份 索引构建和实时维护（拆分异构索引、倒排 ...

1. Kafka简介Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输 同时支持离线数据处理和实时数据处理 Scale out：支持在线水平扩展 2. Kafka架构Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处） Partition：Parition是物理上的概念，每个Topic包含一个或多个Partition. Producer：负责发布消息到Kafka broker Consumer：消息消费者 ...