1、轮询(Polling)是指不管服务器端有没有更新，客户端(通常是指浏览器)都定时的发送请求进行查询，轮询的结果可能是服务器端有新的更新过来，也可能什么也没有，只是返回个空的信息。不管结果如何，客户端处理完后到下一个定时时间点将继续下一轮的轮询。
2、长轮询(Long Polling)的服务其客户端是不做轮询的，客户端在发起一次请求后立即挂起，一直到服务器端有更新的时候，服务器才会主动推送信息到客户端。 在服务器端有更新并推送信息过来之前这个周期内，客户端不会有新的多余的请求发生，服务器端对此客户端也啥都不用干，只保留最基本的连接信息，一旦服务器有更新将推送给客户端，客户端将相应的做出处理，处理完后再重新发起下一轮请求。可见，长轮询的特点：
- 服务器端会阻塞请求直到有数据传递或超时才返回；
- 客户端响应处理函数会在处理完服务器返回的信息后，再次发出请求，重新建立连接；
- 当客户端处理接收的数据、重新建立连接时，服务器端可能有新的数据到达；这些信息会被服务器端保存直到客户端重新建立连接，客户端会一次把当前服务器端所有的信息取回。
websocket
轮询和长轮询都是使用普通的HTTP协议传输数据，它只允许client单方面发起请求，然后server进行响应，而不能主动给client发送数据。
WebSocket协议是HTML5定义的一种新协议，它实现了浏览器与服务器全双工通信(full-duplex)。
webosocket使用HTTP请求握手，握手之后，就不再使用HTTP请求，可以在client与server之间进行数据交换时避免反复传输http headers。
Long Polling长轮询详解
众所周知，数据交互有两种模式：Push（推模式）、Pull（拉模式）。
推模式指的是客户端与服务端建立好网络长连接，服务方有相关数据，直接通过长连接通道推送到客户端。其优点是及时，一旦有数据变更，客户端立马能感知到；另外对客户端来说逻辑简单，不需要关心有无数据这些逻辑处理。缺点是不知道客户端的数据消费能力，可能导致数据积压在客户端，来不及处理。
拉模式指的是客户端主动向服务端发出请求，拉取相关数据。其优点是此过程由客户端发起请求，故不存在推模式中数据积压的问题。缺点是可能不够及时，对客户端来说需要考虑数据拉取相关逻辑，何时去拉，拉的频率怎么控制等等。
详解
说到Long Polling（长轮询），必然少不了提起Polling（轮询），这都是拉模式的两种方式。
Polling是指不管服务端数据有无更新，客户端每隔定长时间请求拉取一次数据，可能有更新数据返回，也可能什么都没有。
Long Polling原理也很简单，相比Polling，客户端发起Long Polling，此时如果服务端没有相关数据，会hold住请求，直到服务端有相关数据，或者等待一定时间超时才会返回。返回后，客户端又会立即再次发起下一次Long Polling。这种方式也是对拉模式的一个优化，解决了拉模式数据通知不及时，以及减少了大量的无效轮询次数。（所谓的hold住请求指的服务端暂时不回复结果，保存相关请求，不关闭请求连接，等相关数据准备好，写会客户端。）
前面提到Long Polling如果当时服务端没有需要的相关数据，此时请求会hold住，直到服务端把相关数据准备好，或者等待一定时间直到此次请求超时，这里大家是否有疑问，为什么不是一直等待到服务端数据准备好再返回，这样也不需要再次发起下一次的Long Polling，节省资源？
主要原因是网络传输层主要走的是tcp协议，tcp协议是可靠面向连接的协议，通过三次握手建立连接。但是所建立的连接是虚拟的，可能存在某段时间网络不通，或者服务端程序非正常关闭，亦或服务端机器非正常关机，面对这些情况客户端根本不知道服务端此时已经不能互通，还在傻傻的等服务端发数据过来，而这一等一般都是很长时间。当然tcp协议栈在实现上有保活计时器来保证的，但是等到保活计时器发现连接已经断开需要很长时间，如果没有专门配置过相关的tcp参数，一般需要2个小时，而且这些参数是机器操作系统层面，所以，以此方式来保活不太靠谱，故Long Polling的实现上一般是需要设置超时时间的。
Guava工程包含了若干被Google的 Java项目广泛依赖 的核心库，例如：集合 [collections] 、缓存 [caching] 、原生类型支持 [primitives support] 、并发库 [concurrency libraries] 、通用注解 [common annotations] 、字符串处理 [string processing] 、I/O 等等。 所有这些工具每天都在被Google的工程师应用在产品服务中。
Google Guava官方教程（中文版）
原文链接 译文链接 译者: 沈义扬，罗立树，何一昕，武祖 校对：方腾飞
引言
Guava工程包含了若干被Google的 Java项目广泛依赖 的核心库，例如：集合 [collections] 、缓存 [caching] 、原生类型支持 [primitives support] 、并发库 [concurrency libraries] 、通用注解 [common annotations] 、字符串处理 [string processing] 、I/O 等等。 所有这些工具每天都在被Google的工程师应用在产品服务中。
查阅Javadoc并不一定是学习这些库最有效的方式。在此，我们希望通过此文档为Guava中最流行和最强大的功能，提供更具可读性和解释性的说明。
译文格式说明
- Guava中的类被首次引用时，都会链接到Guava的API文档。如：Optional<T>。
- Guava和JDK中的方法被引用时，一般都会链接到Guava或JDK的API文档，一些人所共知的JDK方法除外。如：Optional.of(T), Map.get(key)。
- 译者对文档的额外说明以斜体显示，并且以“译者注：”开始。
目录
1. 基本工具 [Basic utilities]
让使用Java语言变得更舒适
1.1 使用和避免null：null是模棱两可的，会引起令人困惑的错误，有些时候它让人很不舒服。很多Guava工具类用快速失败拒绝null值，而不是盲目地接受
1.2 前置条件: 让方法中的条件检查更简单
1.3 常见Object方法: 简化Object方法实现，如hashCode()和toString()
1.5 Throwables：简化了异常和错误的传播与检查
2. 集合[Collections]
Guava对JDK集合的扩展，这是Guava最成熟和为人所知的部分
2.1 不可变集合: 用不变的集合进行防御性编程和性能提升。
2.2 新集合类型: multisets, multimaps, tables, bidirectional maps等
2.3 强大的集合工具类: 提供java.util.Collections中没有的集合工具
2.4 扩展工具类：让实现和扩展集合类变得更容易，比如创建Collection的装饰器，或实现迭代器
3. 缓存[Caches]
Guava Cache：本地缓存实现，支持多种缓存过期策略
4. 函数式风格[Functional idioms]
Guava的函数式支持可以显著简化代码，但请谨慎使用它
5. 并发[Concurrency]
强大而简单的抽象，让编写正确的并发代码更简单
5.1 ListenableFuture：完成后触发回调的Future
5.2 Service框架：抽象可开启和关闭的服务，帮助你维护服务的状态逻辑
6. 字符串处理[Strings]
非常有用的字符串工具，包括分割、连接、填充等操作
7. 原生类型[Primitives]
扩展 JDK 未提供的原生类型（如int、char）操作， 包括某些类型的无符号形式
8. 区间[Ranges]
可比较类型的区间API，包括连续和离散类型
9. I/O
简化I/O尤其是I/O流和文件的操作，针对Java5和6版本
10. 散列[Hash]
提供比Object.hashCode()更复杂的散列实现，并提供布鲁姆过滤器的实现
11. 事件总线[EventBus]
发布-订阅模式的组件通信，但组件不需要显式地注册到其他组件中
12. 数学运算[Math]
优化的、充分测试的数学工具类
13. 反射[Reflection]
Guava 的 Java 反射机制工具类
原创文章，转载请注明： 转载自并发编程网 – ifeve.com本文链接地址: Google Guava官方教程（中文版）
添加本文到我的收藏
适用性
缓存在很多场景下都是相当有用的。例如，计算或检索一个值的代价很高，并且对同样的输入需要不止一次获取值的时候，就应当考虑使用缓存。
Guava Cache与ConcurrentMap很相似，但也不完全一样。最基本的区别是ConcurrentMap会一直保存所有添加的元素，直到显式地移除。相对地，Guava Cache为了限制内存占用，通常都设定为自动回收元素。在某些场景下，尽管LoadingCache 不回收元素，它也是很有用的，因为它会自动加载缓存。
通常来说，Guava Cache适用于：
- 你愿意消耗一些内存空间来提升速度。
- 你预料到某些键会被查询一次以上。
- 缓存中存放的数据总量不会超出内存容量。（Guava Cache是单个应用运行时的本地缓存。它不把数据存放到文件或外部服务器。如果这不符合你的需求，请尝试Memcached这类工具）
如果你的场景符合上述的每一条，Guava Cache就适合你。
如同范例代码展示的一样，Cache实例通过CacheBuilder生成器模式获取，但是自定义你的缓存才是最有趣的部分。
注：如果你不需要Cache中的特性，使用ConcurrentHashMap有更好的内存效率——但Cache的大多数特性都很难基于旧有的ConcurrentMap复制，甚至根本不可能做到。
Diamond 高可用配置中心
