问题的提出

在java webapp开发过程中有很多需要下载图片的需求，一般情况下我们都是用tomcat/jetty等类似的java web 容器提供java web程序运行服务，由于web容器可以直接提供http服务，所以架构师往往就直接使用java容器来直接提供图片的下载服务，这种做法往往带来的大量用户下载是web容器运行效率不佳，有时会影响servlet页面的处理效率。尽管现代的web容器做了深度优化，处理效率比之以前大大提高，但是一旦用户数量上去后，依然存在进程假死，不提供服务的问题。

深入分析

为什么使用java容器提供图片下载会出现这样的情况呢？我们首先需要看一下磁盘io的过程或者说步骤：

1. 应用程序通过io api发出数据读取请求
2. 如果是java程序，java进程通过jvm对操作系统发出请求
3. 操作提供接收到指令从磁盘读取数据，现代操作系统都具备缓存功能，如果缓存中存在符合要求的数据块，则直接返回
4. 操作系统对磁盘发出去读取数据请求，现代的磁盘一般也有缓存功能，如果缓存中存在符合要求的数据块，则直接返回
5. 操作系统监控磁盘的数据读取操作，如果读取完成，此时数据被放在称作内核态的内存区域，此时操作系统需要把数据复制到用户态的内存中

这样数据有一个复制的过程，会消耗更多的资源和时间，如果使用java.io话，jvm会把复制到用户态内存的数据切成小块在返回个java app，这样java处理文件的效率会更加低效。现在的操作系统提供了一种称之为“mmap”的技术，可以直接把内核态的内存地址映射成用户态的地址，这样减少了用户态和内核态内存拷贝的消耗，提高了性能。自从jdk1.4，java也引入了使用mmap的技术，提高了效率。一般情况下，web容器提供文件服务时首先需要读取文件数据到内存然后通过tcp发送个客户端浏览器，这个是通过jvm来处理的，一般情况下多了jvm这一层，效率并不会产生太大影响，但一旦用户数上来这看似很小的性能消耗会被无限放大，直接现象就是web容器不能提供服务。另一方面io本身就是一个相对慢的操作，即使是使用c开发，当用户量急剧上升时也可能会出现问题。所以现代操作系统提供了一个叫sendfile的技术，这是在操作系统级别做了优化的技术，可以提供高效的文件读取和传输，很多web服务器比如apache/nginx/lighthttpd都基于这个技术提供了组件，但遗憾的是无论是tomcat还是jetty都还不能提供这个支持。还有一个问题是java的tcp通讯模型问题，虽然java底层已经支持epoll模式，但jdk层的封装上还是selector模式，这与操作系统原生的epoll模式在网络接入和处理上存在差距。基于这3个方面的原因造成了java web容器的问题。

解决方案

通用的技术解决方案

一般的解决方案的核心就是：让专业的人做专业的事。java web容器的作用是运行java web程序，运行动态页面，读取数据库，处理业务逻辑，对于一下静态的页面、图片、文件等直接让apache、nginx或者lighthttpd来提供服务。同时apache层还可以作为负载均衡，动态转发http请求到多个web 容器。

apache提供的图片服务方案

alias方案apache支持别名技术，所谓的别名就是当用户请求一个资源时，apache根据配置规则自动把请求的资源转换到一个看似毫不相关的本地文件系统资源，比如:

Alias /foo/bar /baz
Alias /foo /gaq

当用户请求/foo/bar时，apache会自动从/baz获取资源，结合url rewrite可以提供更为强大的功能。这种方案在处理不需要权限判断的资源时非常有效，但需要权限判断的资源则不适合。

sendfiles方案

apache提供sendfiles技术的支持，需要安装一个特定的组件。其核心原理是：web程序通过response写入一个特定的header:X-Sendfile,当apache收到该response时会自动识别，然后自动读取需要下载的文件路径，并且读取文件发送至客户端浏览器。这样就可以进行权限判断了，文件下载的步骤是：

1. 客户端请求一个文件
2. apache转发原始请求至web容器
3. web app进行权限判断
4. web app根据请求参数查询出文件路径，并且写header
5. apache截获response，根据header信息判断是否使用sendfiles技术，发送数据