前言

曾经被问到过为什么Oauth2的认证中需要一个授权码，当时的分析觉得是为了安全性。当时开发时也没有阅读过Oauth2的规范。没有仔细分析过原因，只是知道Oauth2分了好几种认证方式。今天就看看究竟是什么原因。

Oauth2认证分类和流程参考资料

https://blog.yorkxin.org/2013/09/30/oauth2-4-1-auth-code-grant-flow
https://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1.3.1
理解OAuth 2.0
https://oauth.net/2/
http://stackoverflow.com/questions/8666316/facebook-oauth-2-0-code-and-token

结论

1. 从以上的参考资料可以了解到，为什么使用授权码，这个问题本身就是不成立的。因为简化版这种授权类型就不用授权码。这中类型的授权是针对JS客户端的（没有后端服务器）。
2. 基于授权码这种认证方式存在的原因是：安全性。

The authorization code provides a few important security benefits such as the ability to authenticate the client, and the transmission of the access token directly to the client without passing it through the resource owner’s user-agent, potentially exposing it to others, including the resource owner.

关于Executors这个类的用法可以参考jdk文档或：https://my.oschina.net/20076678/blog/33392。在本文我只想提出一个问题，就是newCachedThreadPool()这个方法。 该方法的逻辑如下：

1
2
3
4
5

 public static ExecutorService newCachedThreadPool() {
        return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
                                      60L, TimeUnit.SECONDS,
                                      new SynchronousQueue<Runnable>());
}

该方法创建的线程池的核心线程数等于零，最大线程数为Integer.MAX_VALUE。 这就说明了，如果我提交任务的速度很快，并且任务比较耗时，那么服务器就会因为线程数过多而负载飙升而挂断（会影响其他正常执行的业务线程，并且每个线程都会占用内存）。所以这点需要注意。在使用线程池的时候尽量使用固定数目的线程，和有界队列并配合自定义的拒绝执行处理器来处理任务。如果有可能，不同类型的任务可以使用不同的线程池。这样可以将任务分类和隔离，不至于因一类任务的问题导致整个服务不可用。

背景

面试被问到kafka消息发送是分区选择的策略，当时回答说是随机选择一个分区；或者通过消息key的hash值和分区数计算出分区。当时只是猜测的，并没有查看过kafka的源代码来证实，今天就通过源码来证实一下。

本文翻译自:http://www.journaldev.com/1053/java-thread-dump-visualvm-jstack-kill-3-jcmd

Java 线程堆栈

Java线程堆栈用来分析应用的瓶颈和线程死锁问题是非常有用的。

下面介绍一些生成Java线程堆栈的方法。这些方式都是基于*nix操作系统，在windows上可能有所不同。

本文翻译自http://www.journaldev.com/1044/thread-life-cycle-in-java-thread-states-in-java

前言

如果你在工作中会用到线程或者你需要编写多线程程序，那么理解Java线程的生命周期和线程状态是非常重要的。

前言

java 中Thread类的join方法用法有时会出现在面试中，但是在日常的开发中很少看到这样的用法。下面就介绍下这个方法的作用。

前言

Java线程池的工作原理在面试时有很大的概率被问到，大部分人也能回答正确。但有一个小细节可能会忽略，那就是线程池的拒绝执行策略。今天翻看JDK的源码详细整理一下这个问题的答案。

前言

对大多数Java开发人员来说，Java中的内存映射文件都是一个新的概念，即使它早在JDK1.4时已经被添加到包java.nio中了。在引入NIO和内存映射文件后，Java中拥有了非常快的IO操作能力，这也是为什么高性能Java应用程序使用内存映射文件来持久化数据的主要原因。它已经在高频交易系统中非常流行了，其中电子交易系统需要超快速，并且单向交换的延迟必须在亚微秒级别上。 IO一直是性能敏感的应用程序中需要关注的，内存映射文件允许你通过使用直接和非直接字节缓冲区直接从内存读取和写入内存。

本文翻译自：http://javarevisited.blogspot.jp/2015/08/difference-between-direct-non-direct-mapped-bytebuffer-nio-java.html

前言

ByteBuffer 是Java NIO API 中一个非常重要的类。它是在JDK1.4中首次添加的，位于包java.nio中。它不仅允许你操作堆内的字节数组，同时也允许你操作JVM堆外的直接内存。 ByteBuffer有三个主要的类型：DirectByteBuffer, HeapByteBuffer 和 MappedByteBuffer。你可以通过java.nio.ByteBuffer类创建直接或非直接字节缓存。 MappedByteBuffer是ByteBuffer的子类，可以通过FileChannel.map()方法来创建，可以用来操作内存映射文件。 直接字节缓存和非直接内存缓存的主要区别在于内存的位置。 非直接内存缓存只是字节数组的包装类，且在Java Heap上。直接字节缓存是位于JVM堆之外的内存区域。

本文转载自：http://javarevisited.blogspot.jp/2013/01/difference-between-stack-and-heap-java.html

前言

在开始学习Java和其他的编程语言时，有个经常被问到的问题就是关于栈和堆的区别。栈和堆是程序员开始编程时最早听到的两个词，但是关于这两者并没有清晰和明确的解释。在Java中缺少对什么是堆，什么是栈的认识会导致关于两者之间错误的认知。Java提供栈这个数据结构，它以LIFO（先进先出）顺序存储元素，在Java API中以java.util.Stack提供，这更增加了堆和栈之间迷惑性。 一般来说，栈和堆都是内存的一部分，一个程序中分配的并用于不同的目的。 Java程序在JVM上运行，它通过“java”命令进程启动。 Java也使用栈和堆内存来满足不同的需求。