Netty 组件：

• Bootstrap / ServerBootstrap
• EventLoop
• EventLoopGroup
• ChannelPipeline
• Channel
• Future / ChannelFuture
• ChannelInitializer
• ChannelHandler

接下来将会在本章对上面组件进行介绍，为了避免分散地介绍它们，我们将详细说明它们是如何在一起工作的。

本章内容主要介绍：

• Netty 架构
• 我们为什么需要非阻塞IO
• 阻塞IO vs 非阻塞IO
• 了解 JDK 的 NIO实现的问题和 Netty 的解决方法

前面关于 Netty 架构的省略。

异步的设计

整个 Netty 的 API 都是异步的。异步处理并不新鲜，已经出现有一段时间了。在这些年里，IO 经常出现瓶颈，所以异步处理变得越来越重要。

在使用资源时调用异步处理可以变得更有效率，因为当任务进行时，我们可以去干其他事，直到我们收到任务完成的信息。

Netty 官网

可以到官网下载，也可以直接使用 maven 依赖：

1
2
3
4
5
6
7
8

<dependencies>
    <dependency>
        <groupId>io.netty</groupId>
        <artifactId>netty-all</artifactId>
        <version>4.1.30.Final</version>
        <scope>compile</scope>
    </dependency>
</dependencies>

减少HTTP请求，是雅虎前端性能优化35条军规的第1条，2006年雅虎提出了这35条军规，从那以后，就深深地影响到了一批又一批的前端开发者，即使在12年后的今天，影响力依旧不减…

但是，雅虎军规中还有1条是：拆分资源以最大化利用浏览器并行下载的能力。现在问题就来了，减少HTTP请求，但网页所需的资源并不能减少（否则网页就不再是之前的网页了），所以减少HTTP请求，主要是通过合并资源来实现的，一边是建议合并资源，一边是建议拆分资源，显然是有冲突的地方，那么到底该怎么做呢？网上有些文章也讨论过这个问题，但大多是停留在想当然的理论分析上，而且忽略了TCP传输机制的影响。

强引用（StrongReference）

如果一个对象具有强引用，那垃圾回收器（Garbage Collection，GC）绝不会回收它。当内存空间不足，JVM 宁愿抛出 OutOfMemoryError，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。

原文Spring中获取request的几种方法，及其线程安全性分析

前言

本文将介绍在使用 Spring MVC 开发中，获取 request 对象的几种方法，并讨论其线程安全性。

概述

在使用 Spring MVC 开发 Web 系统时，经常需要在处理请求时使用 request 对象。比如：获取客户端 IP 地址、请求的 URL、header 中的属性（Cookie、授权信息）、body 中的数据等。

由于在 Spring MVC 中，处理请求的 Controller、Service 等对象都是单例的，因此获取 request 对象时最需要注意的问题，便是 request 对象是否线程安全：当有大量并发请求时，能否保证不同请求/线程中使用不同的 request 对象。

Java 虚拟机（JVM）

Java 源码，经过编译器编译后生成 .class 字节码文件：

Java 源码编译由以下三个过程组成：

• 分析和输入到符号表
• 注解处理
• 语义分析和生成class文件

JVM 将字节码文件翻译成特定平台下的机器码然后运行：

注：编译生成的是字节码，字节码不能直接运行，必须通过 JVM 翻译成机器码才能运行。不同平台下编译生成的字节码是一样的，但是由 JVM 翻译成的机器码却不一样。

注：跨平台的是 Java 程序，不是 JVM。JVM 是用 C/C++ 开发的，不能跨平台，不同平台下需要安装不同版本的 JVM。