- 博客(184)
- 资源 (8)
- 收藏
- 关注
RSS订阅
原创 Java容器源码面试知识点汇总（超详细！）
Java容器源码(一)——ArrayList源码分析(基于JDK8)Java容器源码(二)——Vector源码分析(基于JDK8)Java容器源码（三）——CopyOnWriteArrayList源码分析（基于JDK8）Java容器源码（四）——LinkedList源码分析（基于JDK8）Java容器源码（五）——HashMap源码分析（基于JDK8）Java容器源码（六）——HashS...
2019-09-20 15:19:15
1034
原创 Java并发面试知识点汇总（超详细！）
Java并发编程知识点总结（一）——并发编程基础知识Java并发编程知识点总结（二）——线程的状态Java并发编程知识点总结（三）——Java内存模型以及Happens-Before原则Java并发编程知识点总结（四）——Synchronized实现原理以及优化Java并发编程知识点总结（五）——volatile实现原理Java并发编程知识点总结（六）——多线程下的final关键字Java并发编程知识点总结（七）——原子性、有序性、可见性Java并发编程知识点总结（八）——AQS源码分析之独占
2019-09-18 10:53:20
3441
1
原创 Python数据分析在数学建模中的应用汇总（持续更新中！）
（一）、Numpy库的使用1、Numpy常用方法使用大全（超详细）（二）、Pandas库的简单使用1、Series和DataFrame简单入门2、Pandas操作CSV文件的读写3、Pandas处理DataFrame，Series进行作图（三）、Matplotlib库进行绘图1、Matplotlib绘图之属性设置2、Matplotlib绘制误差条形图、饼图、等高线图、3D柱形图（...
2019-07-29 22:26:33
7126
2
原创 深入理解ConcurrentHashMap1.8源码
之前介绍了ConcurrentHashMap1.7，采用的是数组+分段锁的方式来实现的。虽然说采用分段锁的方式能够在一定程度上提高并发的效率，但是锁的粒度是Segment级别的，其实还是挺大的。于是，ConcurrentHashMap1.8继续在1.7版本上进行改进，将锁的粒度进一步减小，变成Node级别，又提升了并发的效率。
2022-12-31 15:56:38
1058
原创 深入理解ConcurrentHashMap1.7源码
ConcurrentHashMap1.7的设计思想还是很精妙的，值得我们学习。它将所有的HashEntry分配到多个Segment上，当进行put，remove等修改操作的时候，不需要锁整个ConcurrentHashMap，只需要锁修改的HashEntry所在的段，一定程度上提高了并发的效率。对于ConcurrentHashMap1.7的扩容，只能对Segment内的HashEntry数组进行扩容，不能增加Segment的个数。ConcurrentHashMap1.7 最最最最最详细源码分析。
2022-12-31 10:17:35
1096
原创 深入理解ConcurrentLinkedQueue源码
ConcurrentLinkedQueue的设计方式采用的是延迟更新头指针和尾指针。通常我们为了保证同步，在入队和出队的时候需要加入synchronized或者锁，但是这种方式是消耗很大的。而Doug Lea大师使用CAS的方式轻松化解线程不安全问题。其实他也可以通过自旋的方式来做到实时更新头指针和尾指针，但是这会带来一定的消耗。延迟更新的设计方式则可以大大减少CAS的次数，提升效率。并发容器之ConcurrentLinkedQueue。
2022-12-30 23:03:53
779
原创 Java重点源码回顾——HashMap1.8
在之前的文章中，我们介绍了HashMap1.7的源码，今天我们来看下HashMap1.8的源码。HashMap1.8相比于1.7最大的改变就是改变了1.7中采用数组+链表的方式存储键值对，转而由数组+链表+红黑树的方式来存储键值对。HashMap1.8的底层结构如下图所示：当链表中结点数较少（小于8）的时候，还是采用数组+链表的方式。当链表中结点过多，就会造成查找效率低下的情况，就会转而采用数组+红黑树的方式。
2022-12-30 20:45:43
1110
原创 Java重点源码回顾——HashMap1.7
HashMap在我们的日常使用中非常多，所以今天来阅读下它的源码，了解它具体的设计思想，能够帮助我们扩宽视野。HashMap两个主要的版本是1.7和1.8，都是线程不安全的。1.8版本是在1.7版本的基础上引入了红黑树等优化，提升整体的效率。今天我们先来简单了解下HashMap1.7版本的源码。它的主要特点总结如下：在HashMap1.7中，并没有引入红黑树。所以采用的方式还是拉链法。因为HashMap1.7是采用拉链法存储数据的，所以需要将key-value键值对封装成一个节点类，如下所示：从代码上
2022-12-30 16:44:51
927
原创 Java容器源码重点回顾——LinkedList
.LinkedList是。LinkedList的底层数据结构是链表，。因为LinkedList实现了Deque接口，这也是使它具有双端队列的特性。此外，
2022-12-17 16:10:44
633
原创 Java容器源码重点回顾——CopyOnWriteArrayList
CopyOnWriteArrayList就是针对了读写场景下互斥的缺陷，进行优化。它在每次需要进行修改的时候，先拷贝一份原来的数组，在拷贝的新数组上进行修改，最后再将引用指向新数组。这样就能保证，有线程在修改时，读线程不会被阻塞。提高了读写的性能。
2022-12-16 17:24:55
460
原创 Java容器源码重点回顾——Vector
Vector是一个古老的类，现在很少使用了，基于数组实现的，是一个动态数组，数组容量是可以自动增长的。（注意：Vector只能保证单个方法的线程安全，组合方法是没法保证线程安全，具体可见）因为Vector和ArrayList的代码极为相似，建议没有看过ArrayList源码的同学可以先看下。看完ArrayList源码再看Vector就会很轻松。
2022-12-15 17:41:00
705
原创 Java容器源码重点回顾——ArrayList
ArrayList本质上是一个动态数组，是基于数组实现的，其容量是能自动增长。但是ArrayList是线程不安全的。..
2022-12-14 21:40:20
358
原创 生产者和消费者问题
生产者-消费者是一个经典的多线程协作问题。所谓生产者-消费者问题，实际上是包含两类线程，一种是生产者线程，用于生产数据，另一种是消费者线程，用于消费数据。为了解耦生产者和消费者的关系，通常会采用共享的数据区域。生产者往共享区域放数据，无需关心消费者的行为。消费者从共享区域取数据，无需关心生产者的行为。接下来，我们介绍几种方法来完成生产者-消费者模型。
2022-12-13 20:54:48
2880
原创 深入理解ReentrantReadWriteLock源码
之前我们介绍过ReentrantLock，它是基于AQS同步框架实现的，是一种可重入的独占锁。但是这种锁在读多写少的场景下，效率并不高。因为当多个线程在进行读操作的时候，实际上并不会影响数据的正确性。因此针对读多写少的场景，java提供了ReentrantReadWriteLock（可重入读写锁）。读写锁允许同一时刻被多个读线程访问，但是当写线程在访问时，其他所有的读线程和写线程都会被阻塞。ReentrantReadWriteLock是包含读锁和写锁的，从代码中能够看到：读锁和写锁之间是存在一些关系的，具
2022-12-07 10:47:36
527
原创 MySQL如何保证高可用
正常情况下，只要主库执行更新生成的所有binlog，都可以传到备库并被正确执行，备库就能达到跟主库一样的状态，这就是最终一致性。这里我们再放上MySQL主备切换的流程图：主备切换可能是一个主动的运维动作，如软件升级等。也可能是被动操作，如主库所在机器掉电等。主备同步的过程通常有以下三步：所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的事件之间的差值，也就是T3-T1。我们可以在备库上执行show slave status命令，会返回seconds_bebind_master，用于表示当前
2022-12-05 17:44:23
441
原创 深入理解ThreadLocal源码
在之前介绍的多线程编程中，我们通常会利用synchronized或者各种lock来控制临界区资源的同步顺序，从而来解决线程安全问题。这实际是一种时间换空间的优化。线程安全问题的核心就是多个线程会对同一个临界区资源进行操作。ThreadLocal则是采用的是空间换时间的思想，让每个线程都拥有自己的共享资源，各自使用各自的，这样就不会出现线程安全问题。ThreadLocal意为“本地变量”，也就是达到人手一份的效果，不会出现竞争的情况。但是这种方式的缺点就是消耗的内存会大很多。
2022-12-01 16:15:35
451
原创 MySQL如何保证主备一致？
如下图展示的是基本的主备切换流程：在状态1中，主库是A，备库是B，所以客户端的读写都直接方法节点A。由于节点B是节点A的备库，所以备库B只是将A的更新都同步过来，本地执行，这样可以保证节点B和节点A的数据一致性。如果发生主备切换，就会从状态1变成状态2，节点A成为备库，节点B成为主库。在状态1中，虽然节点B没有被客户端直接方法，但是还是接下来我们看下节点A到节点B的流程图：实际上备库B和主库A之间维持了个长连接，主库A中有一个线程（dump_thread），专门用于服务和备库B的长连接。
2022-11-25 15:59:41
699
原创 幻读是什么，幻读有什么问题
如果查询的是主键\索引列，则是行锁。如果查询的是没有主键\索引的话，则是表锁。对于for update加的是行锁还是表锁，可以看面试官问：select…for update会锁表还是锁行？来源：自己整理的MySQL实战45讲笔记。
2022-11-11 17:12:49
3876
原创 普通索引还是唯一索引？
那么肯定会需要在上面建索引，那是从业务上来说，两种索引都可以。但是从性能角度看，是该选择唯一索引还是普通索引呢？为了简单起见，还是用前面的例子来说明。
2022-10-18 15:41:55
480
原创 《Synchronous Double-channel Recurrent Network for Aspect-Opinion Pair Extraction》论文笔记
一、摘要过往的方面级情感分析抽取任务中，往往只会抽取aspect and/or opinions，忽略了它们之间的关系。本文提出的任务是 Aspect-Opinion Pair Extraction(AOPE) 任务，旨在成对抽取aspects和opinions。本文提出的模型是Synchronous Double-channel Recurrent Network（SDRN 同步的双通道循环神经网络）。主要的思想是构建opinion entity extraction unit(观点实体抽取单元)
2021-11-13 22:20:26
804
原创 《Opinion Word Expansion and Target Extraction through Double Propagation》论文笔记
一、摘要本文旨在于解决两方面的问题。opinion lexicon expansion（意见词典扩展）opinion target extraction （意见目标扩展）为了解决上面两方面的问题，通过使用依赖解析器去扩展意见字典和挖掘目标，使得opinion words和targets建立联系。作者使用双向循环的方法来使用信息在opinion words和target之间不断传播。这种方法的好处就是只需要一个初始的opinion字典即可。二、介绍opinion lexicon就是包
2021-11-10 14:39:24
668
原创 《Aspect-Category-Opinion-Sentiment Quadruple Extraction with Implicit Aspects and Opinions》论文笔记
一、摘要产品的评论中包含了许多隐含的方面和意见，但是在以往的方面级情感分析中常常忽略这一点。本文提出了一个新的任务，Aspect-Cateogry-Opinion-Sentiment(ACOS)四元组抽取任务，以此来支持从评论中挖掘更多的隐含方面和意见。此外，作者还构建了两个新的数据集来适应这项任务，Restaurant-ACOS 和 Laptop-ACOS。两个数据集都包含了四元组抽取和隐含的aspects 和 opinions。作者还尝试用四个baseline 系统去进行测试二、介绍
2021-11-10 14:38:10
2524
1
原创 《XLNet:Generalized Autoregressive Pretraining for Language Understanding》论文笔记
一、摘要因为拥有双向建模的能力，降噪的自编码预训练模型（如BERT）通常会比基于自回归的语言模型拥有更好的效果。但是BERT模型也存在缺陷，如忽略了masked位置之间的依赖关系、预训练和微调之间存在差异（预训练有mask标签，应用在下游任务的时候没有mask标签）。本文提出的XLNet，整合了两大类模型的优点，改进了各自的缺点，主要改进：通过最大化所有可能的分解顺序的排列的期望可能性去学习双向的文本依赖。克服了BERT模型的缺点融合了Transformer-XL的思想在BERT论文使
2021-11-10 14:34:27
724
原创 《Transformer-XL_Attentive Language Models Beyond a Fixed-Length Context》论文笔记
一、摘要传统的Transformers受限于固定长度的文本。本文提出了Transformer-XL模型，这个模型使得文本的依赖能够超越固定文本的长度，并且不会产生时间上的错乱。模型由片段级别递归和新型的位置编码方案组成，主要解决了文本长距离依赖和文本碎片化问题，在时间上面也比vanilla Transformer快很多。Transformer-XL模型在enwiki8数据上取得0.99的困惑度，text8上取得1.08困惑度，WikiText-103上取得18.3的困惑度，One Billion
2021-11-10 14:27:49
1269
SemEval数据集.rar
2021-11-11
美赛M奖论文.rar
2020-01-10
计算机组成原理与汇编语言易小琳、鲁鹏程（课件，部分答案，实验）
2019-06-13
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人