1.容器的历史
容器概念始于 1979 年提出的 UNIX chroot，它是一个 UNIX 操作系统的系统调用，将一个进程及其子进程的根目录改变到文件系统中的一个新位置，让这些进程只能访问到这个新的位置，从而达到了进程隔离的目的。
2000 年的时候 FreeBSD 开发了一个类似于 chroot 的容器技术 Jails，这是最早期，也是功能最多的容器技术。Jails 英译过来是监狱的意思，这个“监狱”（用沙盒更为准确）包含了文件系统、用户、网络、进程等的隔离。
2001 Linux 也发布自己的容器技术 Linux VServer，2004 Solaris 也发布了 Solaris Containers，两者都将资源进行划分，形成一个个 zones，又叫做虚拟服务器。
2005 年推出 OpenVZ，它通过对 Linux 内核进行补丁来提供虚拟化的支持，每个 OpenVZ 容器完整支持了文件系统、用户及用户组、进程、网络、设备和 IPC 对象的隔离。
2007 年 Google 实现了 Control Groups( cgroups )，并加入到 Linux 内核中，这是划时代的，为后期容器的资源配额提供了技术保障。
2008 年基于 cgroups 和 linux namespace 推出了第一个最为完善的 Linux 容器 LXC。
2013 年推出到现在为止最为流行和使用最广泛的容器 Docker，相比其他早期的容器技术，Docker 引入了一整套容器管理的生态系统，包括分层的镜像模型，容器注册库，友好的 Rest API。
2014 年 CoreOS 也推出了一个类似于 Docker 的容器 Rocket，CoreOS 一个更加轻量级的 Linux 操作系统，在安全性上比 Docker 更严格。
2016 年微软也在 Windows 上提供了容器的支持，Docker 可以以原生方式运行在 Windows 上，而不是需要使用 Linux 虚拟机。
基本上到这个时间节点，容器技术就已经很成熟了，再往后就是容器云的发展，由此也衍生出多种容器云的平台管理技术，其中以 kubernetes 最为出众，有了这样一些细粒度的容器集群管理技术，也为微服务的发展奠定了基石。因此，对于未来来说，应用的微服务化是一个较大的趋势。
什么是容器？为什么需要它们：
容器是针对以下问题的解决方案：在切换运行环境后，如何保证软件能够可靠地运行？这种切换可能是从程序员的笔记本电脑到测试环境、从某个测试阶段部署到线上，也可能是从数据中心的某台物理机到私有云或者公有云上的某台虚拟机。
使用虚拟化技术时，可以被分发的文件包是一台虚拟机，它包含了整个操作系统和应用。一台运行着三个虚拟机的物理服务器，需要有一个管理虚拟机软件的中间层，以及运行在这个中间层之上的三个独立操作系统。相较之下，一台运行着三个容器应用的服务器，只需要一个操作系统，而每个容器都可以和别的容器共享同一个操作系统内核。操作系统中被容器共享的部分是只读的，如果需要写入，每个容器都可以挂载独立的服务。这也就是说，容器比虚拟机要轻量级很多，它消耗的资源相较于虚拟机也少得多。
一个容器的文件大小可能只有几十M，但是一个拥有完整操作系统的虚拟机却可能是几个G。正因为这一点，对于一个独立服务器来说，它能承载的容器的数量比虚拟机的数量多得多。另一个主要的优点是，虚拟机可能要耗费好几分钟的时间，才能启动操作系统、开始运行应用；然而容器中应用的启动几乎可以瞬间完成。这意味着，如果需要部署更多的容器，它们的实例化可以很快完成；如果不需要这些容器了，也可以很快将它们从宿主服务器上释放掉。第三个优点是，容器化更好地顾及到了模块化。一个复杂的应用可以被细分成小的模块（比如数据库、应用前端等等），而不是将它运行在某一个容器中。这种方式通常被称为“微服务”。使用这种方法构建的应用更容易被管理，因为每个模块都相对简单，而且需要更新某些模块时，不需要重新构建整个应用。因为容器非常轻量级，单独模块（或微服务）只有在它们被需要时才会被实例化，然后几乎瞬间就变得可用了。
Injection
javava EE CDI主要使用@Inject批注，以便将托管bean的依赖注入执行到其他容器托管资源。使用依赖注入的思想是应用程序用到Foo类，Foo类需要Bar类，Bar类需要Bim类，那么先创建Bim类，再创建Bar类并把Bim注入，再创建Foo类，并把Bar类注入，再调用Foo方法，Foo调用Bar方法，接着做些其它工作。