JAVA 如何防止同时 *** 作一个文件

我们通过RandomAccessFile这个随机读取流来 *** 作文件速度上面会有一点慢、但不是极其大的文件一般可以忽略。

我们通过FileChannel对象来获得锁

Trylock

与lock方法

tryLock()是非阻塞式的，它设法获取锁，但如果不能获得，例如因为其他一些进程已经持有相同的锁，而且不共享时，它将直接从方法调用返回。

lock()是阻塞式的，它要阻塞进程直到锁可以获得，或调用lock()的线程中断，或调用lock()的通道关闭。

对独占锁和共享锁的支持必须由底层的 *** 作系统提供。锁的类型可以通过FileLockisShared()进行查询。另外，我们不能获取缓冲器上的锁，只能是通道上的。

File file=new File("D:/testtxt");

//给该文件加锁

RandomAccessFile fis = new RandomAccessFile(file, "rw");

FileChannel fcin=fisgetChannel();

FileLock flin=null;

while(true){

try {

flin = fcintryLock();

break;

} catch (Exception e) {

Systemoutprintln("有其他线程正在 *** 作该文件，当前线程休眠1000毫秒");

sleep(1000);

}

}

Java中的锁主要包括synchronized锁和JUC包中的锁，这些锁都是针对单个JVM实例上的锁，对于分布式环境如果我们需要加锁就显得无能为力。在单个JVM实例上，锁的竞争者通常是一些不同的线程，而在分布式环境中，锁的竞争者通常是一些不同的线程或者进程。如何实现在分布式环境中对一个对象进行加锁呢？答案就是分布式锁。

目前分布式锁的实现方案主要包括三种：

基于数据库实现分布式锁主要是利用数据库的唯一索引来实现，唯一索引天然具有排他性，这刚好符合我们对锁的要求：同一时刻只能允许一个竞争者获取锁。加锁时我们在数据库中插入一条锁记录，利用业务id进行防重。当第一个竞争者加锁成功后，第二个竞争者再来加锁就会抛出唯一索引冲突，如果抛出这个异常，我们就判定当前竞争者加锁失败。防重业务id需要我们自己来定义，例如我们的锁对象是一个方法，则我们的业务防重id就是这个方法的名字，如果锁定的对象是一个类，则业务防重id就是这个类名。

基于缓存实现分布式锁：理论上来说使用缓存来实现分布式锁的效率最高，加锁速度最快，因为Redis几乎都是纯内存 *** 作，而基于数据库的方案和基于Zookeeper的方案都会涉及到磁盘文件IO，效率相对低下。一般使用Redis来实现分布式锁都是利用Redis的 SETNX key value 这个命令，只有当key不存在时才会执行成功，如果key已经存在则命令执行失败。

基于Zookeeper：Zookeeper一般用作配置中心，其实现分布式锁的原理和Redis类似，我们在Zookeeper中创建瞬时节点，利用节点不能重复创建的特性来保证排他性。

在实现分布式锁的时候我们需要考虑一些问题，例如：分布式锁是否可重入，分布式锁的释放时机，分布式锁服务端是否有单点问题等。

上面已经分析了基于数据库实现分布式锁的基本原理：通过唯一索引保持排他性，加锁时插入一条记录，解锁是删除这条记录。下面我们就简要实现一下基于数据库的分布式锁。

id字段是数据库的自增id，unique_mutex字段就是我们的防重id，也就是加锁的对象，此对象唯一。在这张表上我们加了一个唯一索引，保证unique_mutex唯一性。holder_id代表竞争到锁的持有者id。

如果当前sql执行成功代表加锁成功，如果抛出唯一索引异常(DuplicatedKeyException)则代表加锁失败，当前锁已经被其他竞争者获取。

解锁很简单，直接删除此条记录即可。

是否可重入 ：就以上的方案来说，我们实现的分布式锁是不可重入的，即是是同一个竞争者，在获取锁后未释放锁之前再来加锁，一样会加锁失败，因此是不可重入的。解决不可重入问题也很简单：加锁时判断记录中是否存在unique_mutex的记录，如果存在且holder_id和当前竞争者id相同，则加锁成功。这样就可以解决不可重入问题。

锁释放时机 ：设想如果一个竞争者获取锁时候，进程挂了，此时distributed_lock表中的这条记录就会一直存在，其他竞争者无法加锁。为了解决这个问题，每次加锁之前我们先判断已经存在的记录的创建时间和当前系统时间之间的差是否已经超过超时时间，如果已经超过则先删除这条记录，再插入新的记录。另外在解锁时，必须是锁的持有者来解锁，其他竞争者无法解锁。这点可以通过holder_id字段来判定。

数据库单点问题 ：单个数据库容易产生单点问题：如果数据库挂了，我们的锁服务就挂了。对于这个问题，可以考虑实现数据库的高可用方案，例如MySQL的MHA高可用解决方案。

使用Jedis来和Redis通信。

可以看到，我们加锁就一行代码：

jedisset(String key, String value, String nxxx, String expx, int time);

这个set()方法一共五个形参：

第一个为key,我们使用key来当锁，因为key是唯一的。

第二个为value，这里写的是锁竞争者的id，在解锁时，我们需要判断当前解锁的竞争者id是否为锁持有者。

第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set *** 作；若key已经存在，则不做任何 *** 作。

第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期时间的设置，具体时间由第五个参数决定；

第五个参数为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1当前没有锁（key不存在）,那么久进行加锁 *** 作，并对锁设置一个有效期，同时value表示加锁的客户端。2已经有锁存在，不做任何 *** 作。

上述解锁请求中， SET_IF_NOT_EXIST (不存在则执行)保证了加锁请求的排他性，缓存超时机制保证了即使一个竞争者加锁之后挂了，也不会产生死锁问题：超时之后其他竞争者依然可以获取锁。通过设置value为竞争者的id，保证了只有锁的持有者才能来解锁，否则任何竞争者都能解锁，那岂不是乱套了。

解锁的步骤：

注意到这里解锁其实是分为2个步骤，涉及到解锁 *** 作的一个原子性 *** 作问题。这也是为什么我们解锁的时候用Lua脚本来实现，因为Lua脚本可以保证 *** 作的原子性。那么这里为什么需要保证这两个步骤的 *** 作是原子 *** 作呢？

设想：假设当前锁的持有者是竞争者1，竞争者1来解锁，成功执行第1步，判断自己就是锁持有者，这是还未执行第2步。这是锁过期了，然后竞争者2对这个key进行了加锁。加锁完成后，竞争者1又来执行第2步，此时错误产生了：竞争者1解锁了不属于自己持有的锁。可能会有人问为什么竞争者1执行完第1步之后突然停止了呢？这个问题其实很好回答，例如竞争者1所在的JVM发生了GC停顿，导致竞争者1的线程停顿。这样的情况发生的概率很低，但是请记住即使只有万分之一的概率，在线上环境中完全可能发生。因此必须保证这两个步骤的 *** 作是原子 *** 作。

是否可重入 ：以上实现的锁是不可重入的，如果需要实现可重入，在 SET_IF_NOT_EXIST 之后，再判断key对应的value是否为当前竞争者id，如果是返回加锁成功，否则失败。

锁释放时机 ：加锁时我们设置了key的超时，当超时后，如果还未解锁，则自动删除key达到解锁的目的。如果一个竞争者获取锁之后挂了，我们的锁服务最多也就在超时时间的这段时间之内不可用。

Redis单点问题 ：如果需要保证锁服务的高可用，可以对Redis做高可用方案：Redis集群+主从切换。目前都有比较成熟的解决方案。

利用Zookeeper创建临时有序节点来实现分布式锁：

其基本思想类似于AQS中的等待队列，将请求排队处理。其流程图如下：

解决不可重入 ：客户端加锁时将主机和线程信息写入锁中，下一次再来加锁时直接和序列最小的节点对比，如果相同，则加锁成功，锁重入。

锁释放时机 ：由于我们创建的节点是顺序临时节点，当客户端获取锁成功之后突然session会话断开，ZK会自动删除这个临时节点。

单点问题 ：ZK是集群部署的，主要一半以上的机器存活，就可以保证服务可用性。

Zookeeper第三方客户端curator中已经实现了基于Zookeeper的分布式锁。利用curator加锁和解锁的代码如下：

在算法的分布式版本中，我们假设我们有N个Redis主节点。这些节点是完全独立的，因此我们不使用复制或任何其他隐式协调系统。我们已经描述了如何在单个实例中安全地获取和释放锁。我们理所当然地认为，算法将使用此方法在单个实例中获取和释放锁。在我们的示例中，我们设置了 N=5，这是一个合理的值，因此我们需要在不同的计算机或虚拟机上运行 5 个 Redis 主节点，以确保它们以一种基本独立的方式失败。

为了获取锁，客户端执行以下 *** 作：

该算法依赖于以下假设：虽然进程之间没有同步时钟，但每个进程中的本地时间以大致相同的速率更新，与锁的自动释放时间相比，误差幅度很小。这个假设与现实世界的计算机非常相似：每台计算机都有一个本地时钟，我们通常可以依靠不同的计算机来具有很小的时钟漂移。

在这一点上，我们需要更好地指定我们的互斥规则：只要持有锁的客户端在锁有效时间内（如步骤3中获得的那样）终止其工作，减去一些时间（只需几毫秒，以补偿进程之间的时钟漂移），它才能得到保证。

本文包含有关需要绑定 时钟漂移 的类似系统的更多信息： Leases：分布式文件缓存一致性的高效容错机制 。

当客户端无法获取锁时，它应该在随机延迟后重试，以便尝试取消同步多个客户端，尝试同时获取同一资源的锁（这可能会导致没有人获胜的裂脑情况）。此外，客户端在大多数 Redis 实例中尝试获取锁的速度越快，裂脑情况的窗口就越小（并且需要重试），因此理想情况下，客户端应尝试使用多路复用同时将 SET 命令发送到 N 个实例。

值得强调的是，对于未能获取大多数锁的客户端来说，尽快释放（部分）获取的锁是多么重要，这样就不需要等待密钥到期才能再次获取锁（但是，如果发生网络分区并且客户端不再能够与 Redis 实例通信， 在等待密钥过期时需要支付可用性罚款）。

释放锁很简单，无论客户端是否认为它能够成功锁定给定实例，都可以执行。

算法安全吗？让我们来看看在不同场景中会发生什么。

首先，我们假设客户端能够在大多数实例中获取锁。所有实例都将包含一个具有相同生存时间的密钥。但是，密钥是在不同的时间设置的，因此密钥也会在不同的时间过期。但是，如果在时间 T1（我们在联系第一台服务器之前采样之前采样的时间）将第一个键设置为最差，而在时间 T2（我们从最后一个服务器获得回复的时间）将最后一个键设置为最差，则我们确信集中第一个过期的密钥将至少存在 。所有其他密钥稍后将过期，因此我们确信至少这次将同时设置这些密钥。 MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT

在设置大多数密钥期间，另一个客户端将无法获取锁，因为如果 N/2+1 密钥已存在，则 N/2+1 SET NX *** 作无法成功。因此，如果获得了锁，则不可能同时重新获得它（违反互斥属性）。

但是，我们还希望确保尝试同时获取锁的多个客户端无法同时成功。

如果客户端锁定大多数实例的时间接近或大于锁定最大有效时间（我们基本上用于 SET 的 TTL），它将认为锁定无效并将解锁实例，因此我们只需要考虑客户端能够在小于有效时间的时间内锁定大多数实例的情况。在这种情况下，对于上面已经表达的参数，因为任何客户端都不应该能够重新获取锁。因此，仅当锁定大多数实例的时间大于 TTL 时间时，多个客户端才能同时锁定 N/2+1 个实例（“时间”是步骤 2 的结束），从而使锁定无效。 MIN_VALIDITY

系统活动性基于三个主要功能：

但是，我们支付的可用性损失等于网络分区上的 TTL 时间，因此，如果有连续分区，我们可以无限期地支付此罚款。每次客户端获取锁并在能够删除锁之前进行分区时，都会发生这种情况。

基本上，如果存在无限连续的网络分区，则系统可能会在无限长的时间内变得不可用。

许多使用 Redis 作为锁服务器的用户在获取和释放锁的延迟以及每秒可以执行的获取/释放 *** 作数方面都需要高性能。为了满足这一要求，与N Redis服务器对话以减少延迟的策略肯定是多路复用（将套接字置于非阻塞模式，发送所有命令，稍后读取所有命令，假设客户端和每个实例之间的RTT相似）。

但是，如果我们想以崩溃恢复系统模型为目标，则关于持久性还有另一个考虑因素。

基本上，为了看到这里的问题，让我们假设我们配置Redis时根本没有持久性。客户端在 5 个实例中的 3 个实例中获取锁。客户端能够获取锁的其中一个实例重新启动，此时我们可以为同一资源锁定3个实例，而另一个客户端可以再次锁定它，这违反了锁的独占性的安全属性。

如果我们启用AOF持久性，事情将会有所改善。例如，我们可以通过向服务器发送 SHUTDOWN 命令并重新启动它来升级服务器。由于 Redis 过期在语义上是实现的，因此当服务器关闭时，时间仍然会过去，因此我们所有的要求都很好。但是，只要它是干净关闭，一切都很好。停电怎么办？如果 Redis 配置为（默认情况下）每秒在磁盘上同步一次，则重新启动后，我们的密钥可能会丢失。从理论上讲，如果我们想在面对任何类型的实例重启时保证锁定安全，我们需要在持久性设置中启用。由于额外的同步开销，这将影响性能。 fsync=always

然而，事情比乍一看要好。基本上，只要实例在崩溃后重新启动，它就不再参与任何 当前活动的 锁定，算法安全性就会保留。这意味着实例重新启动时的当前活动锁定集都是通过锁定重新加入系统的实例以外的实例而获得的。

为了保证这一点，我们只需要在崩溃后使一个实例不可用，至少比我们使用的最大 TTL 多一点。这是实例崩溃时存在的有关锁的所有密钥变得无效并自动释放所需的时间。

使用 延迟重启 ，即使没有任何可用的Redis持久性，基本上也可以实现安全，但请注意，这可能会转化为可用性损失。例如，如果大多数实例崩溃，系统将全局不可用 TTL （此处全局意味着在此期间根本没有资源可锁定）。

如果客户端执行的工作由小步骤组成，则默认情况下可以使用较小的锁定有效期，并扩展实现锁定扩展机制的算法。基本上，如果客户端在计算过程中锁定有效性接近较低值，则可以通过将Lua脚本发送到所有实例来扩展锁定，该实例扩展密钥的TTL（如果密钥存在并且其值仍然是客户端在获取锁定时分配的随机值）。

只有当客户端能够将锁扩展到大多数实例中，并且在有效时间内（基本上要使用的算法与获取锁时使用的算法非常相似），才应考虑重新获取锁。

但是，这在技术上不会更改算法，因此应限制锁定重新获取尝试的最大次数，否则会违反其中一个活动属性。

在学习java编程开发语言的过程中，我们掌握了线程与线程池等相关技术知识。今天，北大青鸟北京计算机学院就关于线程安全问题给大家做一个简单的说明和介绍，一起来了解一下吧。

线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。

线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据。

什么时候考虑到线程安全：

一个对象是否需要线程安全，取决于该对象是否被多线程访问。这指的是程序中访问对象的方式，而不是对象要实现的功能。要使得对象是线程安全的，要采用同步机制来协同对对象可变状态的访问。Java常用的同步机制是Synchronized，还包括volatile类型的变量，显示锁以及原子变量。在多个线程中，当它们同时访问同个类时，每次执行的结果和单线程结果一致，且变量值跟预期一致，这个类则是线程安全的。

锁的特性

锁机制的两种特性：

互斥性：即同一时间只允许一个线程持有某个对象的锁，通过这种特性来实现多线程中的协调机制，这样在同一时间只有一个线程对需同步的代码块(复合 *** 作)进行访问。互斥性我们也往往称为 *** 作的原子性。

可见性：必须确保在锁被释放之前，对共享变量所做的修改，对于随后获得该锁的另一个线程是可见的，否则另一个线程可能是在本地缓存的某个副本上继续 *** 作从而引起不一致。

挂起、休眠、阻塞和非阻塞

挂起：当线程被挂起时，其会失去CPU的使用时间，直到被其他线程(用户线程或调试线程)唤醒。

休眠：同样是会失去CPU的使用时间，但是在过了指定的休眠时间之后，它会自动激活，无需唤醒(整个唤醒表面看是自动的，但实际上也得有守护线程去唤醒，只是不需编程者手动干预)。

阻塞：在线程执行时，所需要的资源不能得到，则线程被挂起，直到满足可 *** 作的条件。

非阻塞：在线程执行时，所需要的资源不能得到，则线程不是被挂起等待，而是继续执行其余事情，等待条件满足了后，收到了通知(同样是守护线程去做)再执行。

异步的概念和同步相对。

（1）当一个同步调用发出后，调用者要一直等待返回消息（结果）通知后，才能进行后续的执行；

（2）当一个异步过程调用发出后，调用者不能立刻得到返回消息（结果）。实际处理这个调用的部件在完成后，通过 状态、通知和回调 来通知调用者。

这里提到执行部件和调用者通过三种途径返回结果：状态、通知和回调。使用哪一种通知机制，依赖于执行部件的实现，除非执行部件提供多种选择，否则不受调用者控制。

（A）阻塞调用是指调用结果返回之前，当前线程会被挂起，一直处于等待消息通知，不能够执行其他业务

(B)非阻塞调用是指在不能立刻得到结果之前，该函数不会阻塞当前线程，而会立刻返回

场景比喻：

举个例子，比如我去银行办理业务，可能会有两种方式：

在上面的场景中，如果：

a)如果选择排队(同步)，且排队的时候什么都不干(线程被挂起，什么都干不了)，是同步阻塞模型；

b)如果选择排队(同步)，但是排队的同时做与办银行业务无关的事情，比如抽烟，（线程没有被挂起，还可以干一些其他的事），是同步非阻塞模型；

c）如果选择拿个小票，做在位置上等着叫号（通知），但是坐在位置上什么都不干（线程被挂起，什么都干不了），这是异步阻塞模型；

d）如果选择那个小票，坐在位置上等着叫号(通知)，但是坐着的同时还打电话谈生意(线程没有被挂起，还可以干其他事情)，这是异步非阻塞模型。

对这四种模型做一个总结：

1：同步阻塞模型，效率最低，即你专心排队，什么都不干。

2：异步阻塞，效率也非常低，即你拿着号等着被叫（通知），但是坐那什么都不干

3：同步非阻塞，效率其实也不高，因为涉及到线程的来回切换。即你在排队的同时打电话或者抽烟，但是你必须时不时得在队伍中挪动。程序需要在排队和打电话这两种动作之间来回切换，系统开销可想而知。

4：异步非阻塞，效率很高，你拿着小票在那坐着等叫号(通知)的同时，打电话谈你的生意。

linux下几个基本概念

1：用户控件和内核空间。 现代 *** 作系统都是采用虚拟存储器，在32位 *** 作系统下，它的寻址空间(虚拟存储空间)为4G(2的32次方)。为了保证用户进程补鞥呢直接 *** 作内核，保证内核的安全， *** 作系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。对linux *** 作系统而言，将最高的1G字节空间分给了内核使用，称为内核空间，将较低的3G字节的空间划分为用户空间。

2：进程切换很耗资源 ，为了控制进程的执行，内核必须有能力挂起正在cpu上运行的进程，并恢复以前挂起的某个进程的执行，这种行为叫进程的切换。每次切换，要保存上一个的上下文环境等等，总之记住进程切换很耗资源。

3：文件描述符 ：文件描述符在形式上是一个非负整数。实际上，他是一个索引，指向内核为每个进程所维护的该进程打开文件的记录表。当程序打开一个文件时，内核就会向进程返回一个非负整数的文件描述符。但是文件描述符一般在unix，linux系统中才讲。

缓存IO ，大多数系统的默认IO *** 作都是缓存IO,在linux的缓存IO机制中， *** 作系统会将IO的数据缓存在系统的页缓存(page cache)中，也就是说，数据会先被拷贝到 *** 作系统内核的缓冲区，然后才会从 *** 作系统内核的缓冲区拷贝到应用程序的地址空间。 缓存IO的缺点： 数据在传输过程中需要在应用程序和地址空间和内核进行多次数据拷贝 *** 作，这种数据拷贝 *** 作锁带来的cpu以及内存消耗是很大的。

LINUX的IO模型

网络IO的本质是socket的读取。socket在linux系统被抽象为流，故对网络IO的 *** 作可以理解为对流的 *** 作。

对于一次IO访问，比如以read *** 作为例， 数据会先被拷贝到 *** 作系统内核的缓冲区，然后才会从内核缓冲区拷贝到进程的用户层，即应用程序的地址空间 。故当一个read *** 作发生时，其实是经历了两个阶段：

1：内核缓冲区的数据就位

2：数据从内核缓冲区拷贝到用户程序地址空间

那么具体到socket io的一次read *** 来说，这两步分别是：

1：等待网络上的数据分组到达，然后复制到内核缓冲区中

2：数据从内核缓冲区拷贝到用户程序的地址空间(缓冲区)

所以说 网络应用要处理的无非就两个问题：网络IO和数据计算 ，一般来说网络io带来的延迟影响比较大。

网络IO的模型大致有如下几种：

熟悉不？ 我们常说的select，poll和epoll就是属于同步模型中多路复用IO的不同实现方法罢了。 下面分别对同步阻塞，同步不阻塞，同步io复用进行说明。

一：同步阻塞

它是最简单也最常用的网络IO模型。linux下默认的socket都是blocking的。

从图中可以看到，用户进程调用recvfrom这个系统调用后，就处于阻塞状态。然后kernel就开始了IO的第一个阶段：数据准备。等第一个阶段准备完成之后，kernel开始第二阶段，将数据从内核缓冲区拷贝到用户程序缓冲区（需要花费一定时间）。然后kernel返回结果（确切的说是recvfrom这个系统调用函数返回结果），用户进程才结束blocking，重新运行起来。

总结 ： 同步阻塞模型下，用户程序在kernel执行io的两个阶段都被blocking住了 。但是优点也是因为这个，无延迟能及时返回数据，且程序模型简单。

二：同步非阻塞

同步非阻塞就是隔一会瞄一下的轮询方式。同步非阻塞模式其实是可以看做一小段一小段的同步阻塞模式。

三：IO多路复用

由于同步非阻塞方式需要不断的轮询，光轮询就占据了很大一部分过程，且消耗cpu资源。而这个用户进程可能不止对这个socket的read，可能还有对其他socket的read或者write *** 作，那人们就想到了一次轮询的时候，不光只查询询一个socket fd，而是在一次轮询下，查询多个任务的socket fd的完成状态，只要有任何一个任务完成，就去处理它。而且，轮询人不是进程的用户态，而是有人帮忙就好了。那么这就是所谓的 IO多路复用 。总所周知的linux下的select，poll和epoll就是这么干的。。。

selelct调用是内核级别的，selelct轮询相比较同步非阻塞模式下的轮询的区别为： 前者可以等待多个socket，能实现同时对多个IO端口的监听 ，当其中任何一个socket数据准备好了，就返回可读。 select或poll调用之后，会阻塞进程 ，与blocking IO 阻塞不用在于，此时的select不是等到所有socket数据达到再处理，而是某个socket数据就会返回给用户进程来处理。

其实select这种相比较同步non-blocking的效果在单个任务的情况下可能还更差一些 ，因为这里调用了select和recvfrom两个system call，而non-blocking只调用了一个recvfrom，但是 用select的优势在于它可以同时处理多个socket fd 。

在io复用模型下，对于每一个socket，一般都设置成non-blocking，但是其实 整个用户进程是一直被block的 ，只不过用户process不是被socket IO给block住，而是被select这个函数block住的。

与多进程多线程技术相比，IO多路复用的最大优势是系统开销小。

一：select

select函数监视多个socket fs，直到有描述符就绪或者超时，函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。select的基本流程为：

二：poll

poll本质上跟select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd的状态，如果某个fd的状态为就绪，则将此fd加入到等待队列中并继续遍历。如果遍历完所有的fd后发现没有就绪的，则挂起当前进程，直到设备就绪或者主动超时。被唤醒后它又要再次遍历fd。

特点：

1：poll没有最大连接数限制，因为它是用基于链表来存储的，跟selelct直接监听fd不一样。

2：同样的大量的fd的数组被整体复制与用户态和内核地址空间之间。

3：poll还有一个特点是水平触发：如果报告了fd后没有被处理，则下次poll时还会再次报告该fd。

4：跟select一样，在poll返回后，还是需要通过遍历fdset来获取已经就绪的socket。当fd很多时，效率会线性下降。

三：epoll

epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。

效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。

内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

聊聊同步、异步、阻塞与非阻塞

聊聊Linux 五种IO模型

聊聊IO多路复用之select、poll、epoll详解

相信大家在使用电脑的时候都有过这样的现象，就是在运行一个程序的时候，突然发现不需要了或者是需要启用其他软件的时候，我们会强制关闭这个软件的启动过程，辽宁java培训>

以上就是关于JAVA 如何防止同时 *** 作一个文件全部的内容，包括:JAVA 如何防止同时 *** 作一个文件、高并发没锁可不行，三种分布式锁详解、Redis红锁等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！