原文地址 作者：Julien Ponge 译者：iDestiny
资源下载：
如今，多核处理器在服务器，台式机及笔记本电脑上已经很普遍了，同时也被应用在更小的设备上，比如智能手机和平板电脑。这就开启了并发编程新的潜力，因为多个线程可以在多个内核上并发执行。在应用中要实现最大性能的一个重要技术手段是将密集的任务分隔成多个可以并行执行的块，以便可以最大化利用计算能力。
处理并发(并行)程序，一向都是比较困难的，因为你必须处理线程同步和共享数据的问题。对于java平台在语言级别上对并发编程的支持就很强大，这已经在Groovy(GPars)， Scala和Clojure的社区的努力下得以证明。这些社区都尽量提供全面的编程模型和有效的实现来掩饰多线程和分布式应用带来的痛苦。Java语言本身在这方面不应该被认为是不行的。Java平台标准版（Java SE） 5 ，和Java SE 6引入了一组包提供强大的并发模块。Java SE 7中通过加入了对并行支持又进一步增强它们。 阅读全文
原文链接 作者：Tal Weiss 译者：iDestiny 校对：郭蕾
同步区有点像拜访你的公公婆婆。你当然是希望待的时间越短越好。说到锁的话情况也是一样的，你希望获取锁以及进入临界区域的时间越短越好，这样才不会造成瓶颈。
对于方法和代码块，语言层面的加锁机制是synchronized关键字，该关键字是由HotSpot虚拟机内置的。我们在代码中分配的每一个对象，如String、Array或者一个完整的JSON文档，在本地垃圾回收级别都具有内置的加锁能力。JIT编译器也是类似的，它在进行字节码的编译和反编译的时候，都取决于特定的某个锁的具体的状态和竞争级别。
同步块的关键是：进入临界区域内的线程不能超过一个 。这一点对于生产者消费者场景中来说非常糟糕，当一些线程独占地修改某些数据时，而另外一些线程只是希望读取数据，这个是可以和别的线程同时进行的。
HotSpot JVM的并发标记清理收集器(CMS收集器)的主要目标就是：低应用停顿时间。该目标对于大多数交互式应用很重要，比如web应用。在我们看一下有关JVM的参数之前,让我们简要回顾CMS收集器的操作和使用它时可能出现的主要挑战。
就像吞吐量收集器(参见本系列的第6部分),CMS收集器处理老年代的对象,然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程，并且可能是相当长的一段时间，然而这能够使该算法安全地忽略应用程序。相比之下，CMS收集器被设计成在大多数时间能与应用程序线程并行执行，仅仅会有一点(短暂的)停顿时间。GC与应用程序并行的缺点就是，可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行，CMS收集器的GC周期被分为了好几个连续的阶段。
阅读全文
原文地址：http://tutorials.jenkov.com/oauth2/client-credentials-request-response.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
客户端证书授权包含下面的参数：
| grant_type | 必须。必须设置到客户端证书中。 |
| scope | 可选。授权的作用域。 |
客户端授权响应： 客户端授权响应包含下面的参数：
原文地址：http://tutorials.jenkov.com/oauth2/resource-owner-credentials-request-response.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
资源拥有者者密钥证书授权包含单个的请求+响应。 资源拥有者密钥证书授权请求 请求包含下面的参数：
| grant_type | 必须。必须设置到密码中。 |
| username | 必须。UTF-8编码的资源拥有者用户名。 |
| password | 必须。UTF-8编码的资源拥有者密码。 |
| scope | 可选。授权的作用域。 |
资源拥有者密钥证书授权响应 响应是包含访问令牌的JSON结构数据。JSON结构像这样：
原文地址：http://tutorials.jenkov.com/oauth2/implicit-request-response.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
契约授权包含一个请求和一个响应。 契约授权请求 契约授权请求包含下面的参数：
| response_type | 必须。必须被设置在令牌中。 |
| client_id | 必须。当客户端被注册时，有授权服务器分配的客户端标识。 |
| redirect_uri | 可选。由客户端注册的重定向URI。 |
| scope | 可选。请求可能的作用域。 |
| state | 可选(推荐)。任何需要被传递到客户端请求的URI客户端的状态。 |
原文地址：http://tutorials.jenkov.com/oauth2/authorization-code-request-response.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
授权码授权总共由2个请求和2个响应组成。一个授权请求+响应，和一个令牌请求+响应。 授权请求 授权请求被发送到授权端点以获取一个授权码。这是请求中用到的参数：
| response_type | 必须。必须被设置到代码里 |
| client_id | 必须。当客户端被注册时，授权服务器要标识的客户端。 |
| redirect_uri | 可选。通过客户端注册的重定向URI。 |
| scope | 可选。请求可能的作用域。 |
| state | 可选(推荐的)。任何需要被传递到客户端请求的URI客户端的状态。 |
原文地址：http://tutorials.jenkov.com/oauth2/request-response.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
当客户端应用请求授权和访问令牌时，它发送http请求到授权服务器，同它的授权和令牌端点。被发送来回的请求和响应取决于授权类型。记住，这四种授权类型：
每一种授权类型的请求和响应的更多细节将在下文分开地阐释。
原文地址：http://tutorials.jenkov.com/oauth2/endpoints.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
OAuth 2.0定义了一系列端点。端点典型的就是web服务器上的URI。比如，一个Java Servlet, JSP page, PHP page, ASP.NET网页等等。
这些端点定义有：
授权端点和令牌端点都位于授权服务器上，重定向端点位于客户端应用上。每个端点都会在下面讲述。
原文地址：http://tutorials.jenkov.com/oauth2/authorization.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
当一个客户端应用想要访问拥有者托管在资源服务器的资源时，它必须先获得授权，本节将讲述客户端如何获取授权。
客户端标识，客户端密钥和重定向URI
在客户端应用能请求访问资源服务器的资源之前，客户端应用程序，必须先在资源服务器相关联的授权服务器中进行注册。
注册一个一次性的任务。一旦注册了，除非客户端注册被取消了，注册将持续有效。
注册后客户端应用将由授权服务器分配客户端标识和密钥。在授权服务器上，客户端标识和密钥是唯一标识客户端应用的。如果客户端应用注册了多个授权服务器(如Facebook, Twitter和Google等)，每一个授权服务器将发出唯一的标识给该客户端应用。
原文地址：http://tutorials.jenkov.com/oauth2/client-types.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
OAuth 2.0客户端角色被细分为一系列类型和配置，本节将阐述这些类型和配置。
OAuth 2.0规范定义了两种客户端类型：
保密的客户端能够对外部保持客户端密码保密。该客户端密码是由授权服务器分配给客户端应用的。为了避免欺骗，该密码是授权服务器用来识别客户端的。例如一个保密的客户端可以是web应用，除了管理员，没有任何人能够访问服务器和看到该密码。
公有的客户端不能使客户端密码保密。比如移动手机应用或桌面应用会将密码嵌入在内部。这样的应用可能被破解，并且泄漏密码。这同于在用户的浏览器上运行的JavaScript应用。用户可以使用一个JavaScript调试器来寻找到应用程序，并查看客户端密码。
原文地址：http://tutorials.jenkov.com/oauth2/roles.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
OAuth 2.0为用户和应用定义了如下角色：
这些角色在下图中表示为：
OAuth 2.0规范中的角色定义
原文地址：http://tutorials.jenkov.com/oauth2/overview.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
如引言所说的，OAuth 2.0是一个能够使应用彼此访问数据的开放授权协议，这里我们将阐述该协议是怎么工作的以及规范中提到的概念。该图说明了整个授权过程：
原文地址：http://tutorials.jenkov.com/oauth2/index.html
作者：Jakob Jenkov 译者：林浩 校对：郭蕾
OAuth 2.0是一个应用之间彼此访问数据的开源授权协议。比如，一个游戏应用可以访问Facebook的用户数据或者一个基于地理的应用可以访问Foursquare的用户数据等。下面是一张阐述该概念的图：
任何查找树的并发实现都可以通过用一个独占锁保护来完成。通过使用读写锁对并发性能有一定提升，读写锁允许所有只读（查找）操作并发地执行，因为读操作是以共享模式持有锁，然而更新（插入或删除）操作持有独占模式的锁，从而排斥其他所有操作。如果更新操作比较少，这还能接受，但是只要有适量的更新操作，那么更新操作所持有的独占锁将产生线性的瓶颈，从而大大降低性能。通过使用细粒度的锁策略——比如每个节点一个锁，而不是整棵树使用同一个锁——这样我们进一步地提升了并发性能。
阅读全文
Loading...