Alfred的小站

Java线程池利用Executors创建不同的线程池满足不同场景的需求 五种创建方式 为什么使用线程池 降低资源消耗 提高线程的可管理性 Executor框架 J.U.C（Java.util.concurrent）的三个Executor接口 Executor：运行新任务的简单接口，将任务提交和任务执行细节解耦 ExecutorService：具备管理执行器任务生命周期的方法，提交任务机制更完善 ScheduledExecutorService：支持Future和定期执行任务 ThreadPoolExecutor ThreadPoolExecutor的构造函数参数： corePoolSize：核心线程数量 MaximumPoolSize：线程不够用时能够创建的最大线程数 workQueue：任务等待队列 常见队列类型： SynchronouseQueue：直接交接，内部没有容量 LinkedBlokingQueue：无界队列，MaxPollSize参数等于没用了 ArraryBlokingQueue：有界队列 keepAliveTime： 线程池维护线程所允许...

同步器同步器整体架构 六个同步器 ReentrantLock Semaphore CyclicBarrier CountDownLatch Phaser Exchager ReentrantLock和Synchronized异同相同点： 临界区保护（提供锁/解锁的能力） 可重入 都提供线程间的协作 Synchronized基于Monitor，monitor提供Object.wait(),Object.notify() ReentrantLock基于AQS，提供Condition Object，提供await(), signal()等方法 提供锁升级的逻辑 Synchronized：偏向锁->轻量级锁->重量级锁 ReentrantLock：CAS竞争->休眠+排队竞争 都提供等待队列 Synchronized：monitor：entryList，waitList ReentrantLock：CLH队列 区别点： 基于AQS vs 基于Monitor Java生态 vs 非Java生态 Synchronized是非Java的实现 ...

高并发场景（EntrySet、偏向锁、轻量级锁、重量级锁）考虑大量线程竞争一个用户实现的synchronized 块，如图： 在高并发场景，竞争非常激烈。而作为语言的设计者，不能假设synchronized 的块可以迅速完成。图中很多线程竞争一个同步块，按照之前的设计，这个时候这些线程会优先考虑自旋锁。因为同步块需要10ms ，因此多数线程拿不到自旋锁。考虑到CPU执行速度非常快，每10ms 才有一个线程拿到锁。而1ms 可以执行数以10万-百万计的CAS操作。因此这样是非常不划算的： 自旋锁消耗大量计算能力（CPU资源） 大量线程进入WaitSet 这时JVM的解决方案是增加一个EntrySet。如图： 图中线程先用自旋锁竞争进入EntrySet，竞争进入EntrySet只需要少量的cas操作。 如果像图中那样用链表实现EntrySet，新线程进入EntrySet只需要两条指令，第一步创建一个节点，指向EntrySet的第一个元素。第二步，用cas操作将EntrySet的尾部指向新的节点。 这样需要的时间是非常短的，因此多数线程都可以进入EntrySet。 ‌ ...

数据库架构如何设计一个数据库？ 从如下模块出发： 为什么要使用索引？对于数据量大的表而言，查询某一条如果进行全表扫描无疑非常慢，所以需要使用索引。 通过关键信息快速定位 什么样的信息能成为索引主键、唯一键、普通键等 索引的数据结构 建立二叉树进行二分查找 建立B-Tree结构进行查找 建立B+-Tree结构进行查找 建立Hash结构进行查找 MySQL使用B+-Tree进行索引

稀疏、密集索引与搜索引擎稀疏索引与密集索引的区别 密集索引文件中每一个搜索码值都对应一个索引值 叶子结点不仅仅保存键值，还保存有其他列的信息。 密集索引决定了物理表的排列顺序，所以一个表只创建一个密集索引，通常是主键。 稀疏索引文件只为索引码的某些值建立索引项 叶子结点仅保存了键位信息和该行数据的地址（有的稀疏索引仅保存了键位信息及其主键）。 定位到叶子结点之后仍然需要通过地址或者主键信息进一步定位到数据。 在MySQL中的具体分析主要存储引擎 MysISAM 其索引无论是主键索引还是唯一键索引或者普通索引，均为稀疏索引 InnoDB 必须有且仅有一个密集索引 如果一个主键被定义，则主键作为密集索引 如果没有主键被定义，则第一个唯一非空索引作为密集索引 若上述均不满足，InnoDB内部会生成一个隐藏主键作为密集索引 非主键索引（稀疏索引）的叶子结点并不存储行数据的物理地址，而是存储该行的主键值。 故稀疏索引包含两次查找，一次查找到主键值，第二次根据主键值找到数据 MyISAM和InnoDB索引存储对比图 InnoDB使用密集索引，将主键组织...

如何定位并优化慢SQL查询1. 根据慢日志定位慢查询sql使用SQL命令查询慢日志设置1SHOW VARIABLES LIKE '%QUERY%'; 最后两个变量slow_query_log和slow_query_log_file即和慢日志有关，第一个变量控制是否开启慢日志，第二个变量定义慢日志存储位置。 超过long_query_time时间等查询会被记录在慢日志中。 开启慢查询命令打开慢查询： 1SET GLOBAL slow_query_log = ON; 设置慢查询时间： 1SET GLOBAL long_query_time = 1; 直接使用命令设置数据库重启后会还原，想要永久需要到my.cnf配置文件中去设置。 使用sql命令查询慢日志状态1SHOW STATUS like '%slow_queries%'; Slow_queries显示慢查询记录条数。 2. 使用explain等工具分析sql在命令前加explian即可分析 例如： 1EXPLAIN SELECT `name` FROM person_inf...

关键语法GROUP BY根据给定数据列的每个成员对查询结果分组统计，最终得到分组汇总表 满足 : select子句中对列名必须为分组列或者列函数 列函数对于group by子句定义的每个组返回一个结果 案例：表结构： 一张表： 1234-- 查询所有同学的学号、选课数、总成绩select tudent_id,count(course_id),sum(score)from scoregroup by tudent_id 多张表： 12345678-- 查询所有同学的学号、姓名、选课数、总成绩select s.tudent_id,stu.student_name,count(s.course_id),sum(s.score)from score s student stuwhere s.student_id = stu.student_idgroup by s.tudent_id HAVING 通常与GROUP BY子句一起使用 WHERE过滤行，HAVING过滤组 出现在同一sql中的顺序：WHERE->GROUP BY->HAVING 如果省略gro...

事务事务四大特性 原子性 一致性 隔离性 持久性 事务隔离级别查询隔离级别： 1select @@tx_isolation 设置当前session的隔离级别为 读未提交 1set session transaction isolation level read uncommitted 事务并发引起的问题及解决方案 更新丢失 两个事务先后提交，先提交的更新丢失 mysql所有事务隔离级别均可避免此问题 脏读 一个事务读到另一个事务未提交的更新数据 READ-COMMITTED事务隔离级别以上可避免 READ-COMMITTED即只能读到已被提交的数据 不可重复读 事务B在事务A多次读取过程中修改了数据，导致多次读取数据结果不一致 REPEATABLE-READ事务隔离级别及以上可避免 幻读 事务A读取若干行，事务B删除或插入结果集 SERIALIZABLE事务隔离级别及以上可避免 InnoDB在REPEATABLE-READ事务隔离级别上避免了幻读 InnoDB如何在可重复读事务隔离界别做到避免幻读的？ 表像：快照读（非阻塞读）...

OSI七层网络协议模型 第一层 物理层解决两台物理机之间的交互问题，传递比特流。 主要定义了物理设备的标准 如 网线的类型、光纤的接口类型、各种传输介质的传输速率等。 将比特流转化为电流强弱进行传输，到达目的后再转化为数据流。 第二层 数据链路层第一层有错传、数据传输不完整等可能，数据链路层定义了如何格式化数据以进行传输，以及控制如何对物理介质进行访问，通常还提供错误检测和纠错，以确保数据传输的可靠性。 本层将比特数据组成了帧，交换机工作在这一层，对帧解码同时转发到对应方。 第三层 网络层将网络地址翻译成对应的物理地址，并决定如何将数据从发送方路由到接送方，网络层通过综合考虑发送优先权，网络拥塞程度，服务质量以及可选路由的花费来决定传输的最佳路径。 路由器工作在此层，此层数据称为数据包，主要关注IP协议。 第四层 传输层为保证大数据传输的准确性，需要对数据进行切分，切割为一个一个的段落，即Segment进行发送。 传输层解决了主机间的数据传输和传输质量问题，可以说是最重要的一层 进行流量控制，根据可以传输的最大尺寸将数据进行强制分割。同时对每个数据片编号，以便数据到达接收...

TCP/IP四层协议模型