缓存对象池
⑴ 为什么要使用EJB 使用EJB的理由
为什么使用EJB我原先认为这不是一个讨论的话题，因为EJB是J2EE重要的组成部分，可以说没有EJB的J2EE只是一种Web系统，这样的系统非常容易丧失了多层结构的大部分优点（仔细想想那些混合多种层次功能javaBeans和传统两层结构有什么区别？）。
当然，可以人为地在Javabeans之间进行层次划分，例如Hibernate算数据持久层，某些JavaBeans是业务核心层，但是因为都是普通JavaBeans，这种划分没有一种强制性和明显标志性，这样的系统更换了主创人员或设计师，可能就会被新的程序员修改得非常混乱。
我们先看看一个包含EJB的J2EE系统是如何清晰地表达层次。如下图：
Web完全只是一个MVC模式的实现，关键业务核心是在EJB的服务层实现，这样做的优点是，Web只负责界面相关部分，因为，如果是一个智能客户端，如Swing或J2ME，在不需要修改任何业务核心的情况下能够方便地更换。同样，提供Web Services功能，也只是在 Web层修改，不会涉及EJB方面的修改，同样保证了系统的稳定性，保证了系统升级和未来的扩展性。
如果不使用EJB，在EJB服务层实现的业务核心将由普通JavaBeans实现，使用何种架构或设计能够保证负责MVC的JavaBeans和负责业务核心的JavaBeans清晰地分开，又如何保证在新的程序员不会破坏和打乱你精心布局的JavaBeans架构？
EJB提供性能优化支持
最主要的是性能问题，由于以前国内中文Java网站有些人弯曲EJB，认为EJB性能低，其实这是一种非常肤浅错误的认识，我们首先看看在一般Java环境中是如何提高性能。
假定一个JavaBeans为A，那么一般使用这个JavaBeans命令如下：
A a = new A();
但是，在高访问量的环境中，new A()其实是很费时消耗系统性能的，因此，能不能在软件系统启动时候就预先建立一些对象，这样，系统运行时，从这些已经生成的对象池中借用一个，这样，就无需在使用时进行New，节约了开销，提高了性能，因此，真正成熟性能解决方案都是需要对象池等支持。
在一个纯Web结构的系统（也就是只能运行在Tomat环境中），例如Struts Hibernate等这样的系统，除非自己动手做，一般是没有对象池技术支持的，因此他们的性能只能算是Demo演示版本的性能，根本无法承受大容量并发访问，也无法称为一个成熟的系统，所以，我们研究成熟的开源Web系统，如Jive、OFBize，LifeRay等，他们都在Web层拥有自己的对象池和缓存池。
对象池和缓存机制是J2EE必须的吗？当然，是所有成熟系统必须的，Windows系统如果去掉缓存将会变得怎样？
自己动手开发对象池和缓存机制并不是一件简单的事情，需要对多线程以及同步锁等底层原理有深层次的把握，这其实也是一门非常深入的Java研究分支，所以，你可以抛开你的客户焦急的催促，精心研究开发自己的对象池和缓存池。
但是，EJB容器（如JBoss）已经提供了对象池和缓存机制，所以，没有事务机制的无状态Session Bean的性能肯定要强于普通JavaBeans。EJB容器不但在单机中提供了对象池和缓存，而且可以跨服务器实现动态负载平衡，这些都无需开发者自己开发任何软件代码，结构如下：
EJB组件能提供真正的可重用框架
每一个jar包代表一个EJB组件，一个系统可以由多个可重用的EJB组件构成，例如：树形结构EJB组件；自增序号EJB组件；用户资料EJB组件等，这样的EJB组件可以象积木一样搭配在大部分应用系统中，提高了系统的开发效率，保证了开发质量。
下图是某个新的具体系统时应用到的EJB组件图，在这个新的应用中，由于使用了以前大量可重用的EJB组件，新的开发工作基本集中在界面设计和流程安排上：
EJB提供了事务机制
事务机制对于一些关键事务是很重要的，例如ATM机提款，提款有多个动作：修改数据库以及数钱等，如果这其中有任何一个环节出错，那么其它已经实现的操作必须还原，否则，就会出现，提款人没有拿到钱，但是卡上已经扣款等不可思议的事情发生。
EJB提供的事务机制非常周全，但事务机制带来的缺点是性能的降低，因此，有些人认为EJB很重，因为在实际应用中，有的用户系统可能不需要事务机制，只是需要EJB提供的性能优化机制，这样，如果使用EJB，就象叫一个人来背东西，他除了背着我要的东西外，还背着我不要的东西。
除非你是一个完美主义，在一般企业应用或数据库系统应用中，EJB不会对你构成很重的包袱。
CMP独特的优点
开源以及一些数据库持久层技术崇拜者，一直抨击CMP，认为CMP慢无用，实际最大的问题是他们的设计和使用问题。
由于EJB容器（如JBoss）对CMP实现有事务机制的缓存优化，因此，CMP特别适合多个用户同时更新同一个数据源的情况，CMP这种严格的事务完整性保证多个用户同时操作一个数据记录时，能够保证性能优化和数据的完整性，如果这个数据记录是是软件系统的状态标志，它的状态会影响系统中很多的环节，那么状态更改的重要性不言而喻。
如果没有事务完整性支持，你的软件系统在用户访问量变大，就会变得发生各种不可能发生的逻辑错误，查看程序逻辑是正确的，那么问题出在哪里？出在数据完整性上。
由于每个CMP在内存中都有一个缓存，在实际应用中，如果使用CMP批量读数据库数据，几万条查询完毕，内存中充满了几万条CMP缓存，如果这时你的EJB容器设置不当（如使用JBoss缺省配置），那么JVM的垃圾回收机制就会频繁启动，导致你的系统变慢甚至死机，这也是一些人抨击CMP慢的原因所在，其实他们使用方法不当，或者没有正确配置EJB容器CMP缓存。
对于这种情况，根据J2EE核心模式，推荐使用DAO JDBC方式。
小结
除非你对设计模式非常精深，能够将自己系统中的JavaBeans使用模式或某种框架进行固定分层，同时，你孜孜不倦研发出对象池，又熟练于JTA等事务机制，你可以选择没有EJB的纯Web结构，就象Jive、OFBiz那样。当然还有一个前提，老板不懂或者非常有挑战性（做与IBM SUN 微软齐名的公司和技术）。
不要再被TSS那些狂热的开源先生误导，他们有时间有保障可以做他们喜欢的事情，作为专业的J2EE程序员，按照J2EE标准去学习去行动，也不要认为，只要使用了J2EE其中某个技术如Jsp或JavaBeans就心安理得认为自己的系统是J2EE了。
当然，我并不是说纯Web系统不能实现多层结构，但是至少在很多方面没有Web EJB结构完善和清晰，所以，EJB不是J2EE可以忽视的部分，而是主要的重要的部分，重要业务功能核心都封装在EJB中，相反Web层是一种次要的、和界面相关的层次。
⑵ golang sync.pool对象复用 并发原理 缓存池
在go http每一次go serve(l)都会构建Request数据结构。在大量数据请求或高并发的场景中，频繁创建销毁对象，会导致GC压力。解决办法之一就是使用对象复用技术。在http协议层之下，使用对象复用技术创建Request数据结构。在http协议层之上，可以使用对象复用技术创建(w,*r,ctx)数据结构。这样即可以回快TCP层读包之后的解析速度，也可也加快请求处理的速度。
先上一个测试：
结论是这样的：
貌似使用池化，性能弱爆了？？？这似乎与net/http使用sync.pool池化Request来优化性能的选择相违背。这同时也说明了一个问题，好的东西，如果滥用反而造成了性能成倍的下降。在看过pool原理之后，结合实例，将给出正确的使用方法，并给出预期的效果。
sync.Pool是一个 协程安全 的 临时对象池 。数据结构如下：
local 成员的真实类型是一个 poolLocal 数组，localSize 是数组长度。这涉及到Pool实现，pool为每个P分配了一个对象，P数量设置为runtime.GOMAXPROCS(0)。在并发读写时，goroutine绑定的P有对象，先用自己的，没有去偷其它P的。go语言将数据分散在了各个真正运行的P中，降低了锁竞争，提高了并发能力。
不要习惯性地误认为New是一个关键字，这里的New是Pool的一个字段，也是一个闭包名称。其API：
如果不指定New字段，对象池为空时会返回nil，而不是一个新构建的对象。Get()到的对象是随机的。
原生sync.Pool的问题是，Pool中的对象会被GC清理掉，这使得sync.Pool只适合做简单地对象池，不适合作连接池。
pool创建时不能指定大小，没有数量限制。pool中对象会被GC清掉，只存在于两次GC之间。实现是pool的init方法注册了一个poolCleanup()函数，这个方法在GC之前执行，清空pool中的所有缓存对象。
为使多协程使用同一个POOL。最基本的想法就是每个协程，加锁去操作共享的POOL，这显然是低效的。而进一步改进，类似于ConcurrentHashMap（JDK7）的分Segment，提高其并发性可以一定程度性缓解。
注意到pool中的对象是无差异性的，加锁或者分段加锁都不是较好的做法。go的做法是为每一个绑定协程的P都分配一个子池。每个子池又分为私有池和共享列表。共享列表是分别存放在各个P之上的共享区域，而不是各个P共享的一块内存。协程拿自己P里的子池对象不需要加锁，拿共享列表中的就需要加锁了。
Get对象过程：
Put过程：
如何解决Get最坏情况遍历所有P才获取得对象呢：
方法1止前sync.pool并没有这样的设置。方法2由于goroutine被分配到哪个P由调度器调度不可控，无法确保其平衡。
由于不可控的GC导致生命周期过短，且池大小不可控，因而不适合作连接池。仅适用于增加对象重用机率，减少GC负担。2
执行结果:
单线程情况下，遍历其它无元素的P，长时间加锁性能低下。启用协程改善。
结果：
测试场景在goroutines远大于GOMAXPROCS情况下，与非池化性能差异巨大。
测试结果
可以看到同样使用*sync.pool，较大池大小的命中率较高，性能远高于空池。
结论：pool在一定的使用条件下提高并发性能，条件1是协程数远大于GOMAXPROCS，条件2是池中对象远大于GOMAXPROCS。归结成一个原因就是使对象在各个P中均匀分布。
池pool和缓存cache的区别。池的意思是，池内对象是可以互换的，不关心具体值，甚至不需要区分是新建的还是从池中拿出的。缓存指的是KV映射，缓存里的值互不相同，清除机制更为复杂。缓存清除算法如LRU、LIRS缓存算法。
池空间回收的几种方式。一些是GC前回收，一些是基于时钟或弱引用回收。最终确定在GC时回收Pool内对象，即不回避GC。用java的GC解释弱引用。GC的四种引用：强引用、弱引用、软引用、虚引用。虚引用即没有引用，弱引用GC但有空间则保留，软引用GC即清除。ThreadLocal的值为弱引用的例子。
regexp 包为了保证并发时使用同一个正则，而维护了一组状态机。
fmt包做字串拼接，从sync.pool拿[]byte对象。避免频繁构建再GC效率高很多。
⑶ Spring AOP 一般用在什么场景中
AOP，在程序开发中主要用来解决一些系统层面上的问题，比如日志，事务，权限等待，Struts2的拦截器设计就是基于AOP的思想，是个比较经典的例子。
在不改变原有的逻辑的基础上，增加一些额外的功能。代理也是这个功能，读写分离也能用aop来做。
(3)缓存对象池扩展阅读：
AOP/OOP区分
AOP、OOP在字面上虽然非常类似，但却是面向不同领域的两种设计思想。OOP（面向对象编程）针对业务处理过程的实体及其属性和行为进行抽象封装，以获得更加清晰高效的逻辑单元划分。
而AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。这两种设计思想在目标上有着本质的差异。
⑷ 如何获取ceph的缓存池中对象的大小和偏移
连续容器如:Vector，内部是预先分配一段连续缓存来保存对象，所分配内存可以保存对象的个数为容量，而已保存的对象个数为长度。
当程序调用push时候，如果容量不够了，Vector自动重新分配一段缓存，大小是原来的2倍，然后把原来的内容拷贝到新缓存中，最后释放原来的缓存。出现这种情况是很费时间的！所以Vector内部的指针的地址是可能变得的！
list 是每次添加对象的时候动态分配内存，所以没有容量的概念！
⑸ 如何使用对象池缓存节点提高性能
如何使用对象池缓存节点提高性能
因为Redis具有在数据存储中快速读写数据的能力，所以它比关系型数据库更具有性能优势。但是，关键值数据存储是简单的;它们没有一个类似于
SQL的查询语言或者结构化的数据模型。相反，它们有一个把键值作为与数值相关的标识符来使用的简单字典或哈希模式。管理员使用这些键来进行数值的存储和
检索。
键值存储是简单快速的，它可用于实现丰富数据模型和关系型数据库查询功能的良好匹配。但是，有时候还是使用键值与关系型数据库的组合为好。此外，还有很多商业支持的键值数据库，包括Redis、Riak和Areospike等。
⑹ Android图片框架对比
对比现在主流图片框架的优势和缺点，在实际项目中如何选择适合自己的框架；
Glide、Fresco、Picasso、ImageLoader
共同优点：
以上名词介绍
在分析他们的差异、优缺点之前，我们先了解图片缓存通用的概念：
以上概念在不同框架之间可能不同，比如Displayer在ImageLoader中叫做ImageAware,在Picasso和Glide中叫做Target。
以上为Glide的总体设计图。
整个库分为RequestManager（请求管理器）、Engine（数据获取引擎）、Fetcher(数据获取器)、MemoryCache（内存缓存）、DiskLRUCache（本地缓存）、Transformation(图片处理)、Encoder（编码处理）、Registry(图片类型以及解析器配置)、Target(目标)等模块。
简单流程： Glider收到加载及显示资源任务，创建Request并将它交给RequestManager,Request启动Engine去数据源获取资源，得到资源后通过Transformation处理后交给Target.
Glide依赖DiskLRUCache、GifDecoder等开源库去完成本地缓存和Gif图片解密工作；
为Bitmap 维护一个BitmapPool对象池, 对象池的主要目的是通过减少大对象的分配以重用来提高性能!
缺点 ：
①图片质量低：因为机制不同，速度快，但是图片的质量降低了RGB565;
②多尺寸缓存导致内存和磁盘占用多：根据ImageView大小来缓存，可能会导致一张图片可能根据展示情况来缓存不同尺寸的几份；
扩展理解参考： https://www.jianshu.com/p/1ab5597af607
以上为Picasso的总体设计图。
整个库分为Dispatcher、RequestHandler以及Downloader、PicassoDrawable等模块。
简单流程： Picasso收到加载显示图片任务后，创建Request并将它交给Dispatcher，Dispatcher分发任务到具体RequestHandler，任务通过MemoryCache及Handler(数据获取接口)获取图片，图片获取成功后通过PicassoDrawable显示到Target中；
上面Data的File system部分，Picasso没有自定义本地缓存的接口，默认使用http的本地缓存，API19以上使用okhttp,一下使用UrlConnection，所以如果需要自定义本地缓存就需要自定义Downloader;
缺点 ：加载速度没有其他框架快；
特点 ：只缓存一个全尺寸的图片，根据需求的大小在压缩转换；
以上为Fresco的总体设计图
整个库分为UI:DraweeView(View控件)、Drawable（图片数据）、DraweeController（图片控制器）、DraweeHiierarchy（图片体系）；Core:DataSource（数据源）、ImagePipeline（图像管道）、Procer（生产者）、ProcerFacotry(生产工厂)、Subcriber(订阅)、Supplier(供应者)、Consumer（消费者）；IO/Data:MemoryCache(内存缓存)、Network、DiskCache(磁盘缓存)、Recourse（本地资源）
简单流程： 从上面的结构可以看出，fresco主要采用了工厂+建造者的模式实现功能，逻辑划分比较清楚；Fresco框架整体是一个MVC模式，DrawableView--->View用来显示顶层视图、DrawableController--->Control控制加载图片的配置 事件的分发、DrawableHierarchy--->Model 用于存储和描述图片信息，同时也封装了一些图片的显示和视图层级的方法；ImagePipeline模块负责从网络、本地文件系统、本地资源加载图片
缺点：
①框架大，影响Apk体积；
②一定的学习成本，使用比较繁琐，需要使用内部提供的ImageView控件,使用起来比较复杂；
⑺ javascript对象池应用场景是什么样的
具体实现思路：
我们使用一个数组来存储已创建的xmlhttp对象实例，然后每次调用从池中去取一个实例。xmlhttp实例通讯完毕后我们不用做任何处置，因为它自身的readyState属性可以标识出它是否可用，如果当时没有空闲的xmlhttp实例，且池中的实例数小于最大实例个数，那么就创建一个新的实例并放入池中。重新改进的实现代码如下：
复制代码代码如下:
//封装XMLHTTP的MyAjaxObj类
var MyAjaxObj = new Object();
var maxXmlHttpCount = 5; //最多5个xmlhttp对象存在
MyAjaxObj.reqList = []; //可以清空里面的项
MyAjaxObj.getFreeObj = function() {
var req = null;
var len = this.reqList.length;
//先从当前的池里取
for (var i = 0; i < len; i++) {
if (this.reqList[i]) {
if (this.reqList[i].readyState == 4 || this.reqList[i].readyState == 0) {
req = this.reqList[i];
break;
}
}
}
//如果没有闲置的对象，自己独立创建
if (req == null) {
if (this.reqList.length < maxXmlHttpCount) {
req = getXmlHttp();
this.reqList.push(req);
}
}
return req;
}
//创建一个XMLHTTP对象，兼容不同的浏览器
function getXmlHttp() {
var xmlHttp = false;
var arrSignatures = ["MSXML2.XMLHTTP.5.0", "MSXML2.XMLHTTP.4.0",
"MSXML2.XMLHTTP.3.0", "MSXML2.XMLHTTP",
"Microsoft.XMLHTTP"];
for (var i = 0; i < arrSignatures.length; i++) {
try {
xmlHttp = new ActiveXObject(arrSignatures[i]);
return xmlHttp;
}
catch (oError) {
xmlHttp = false; //ignore
}
}
// throw new Error("MSXML is not installed on your system.");
if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
xmlHttp = new XMLHttpRequest();
}
return xmlHttp;
}
/*封装XMLHTTP向服务器发送请求的操作
url:向服务器请求的路径；method：请求的方法，即是get/post；***callback：当服务器成功返回结果时，调用的函数(类似c#回调函数)***
data：向服务器请求时附带的数据；urlencoded：url是否编码；cached:是否使用缓存； callBackError;当服务器返回错误时调用的函数
*/
MyAjaxObj.send = function(url, method, callback, data, urlencoded, cached, callBackError) {
var req = this.getFreeObj(); //从池里或者直接实例化一个XMLHTTP的实例
//当XMLHTTP的请求状态发生改变时调用 (核心处理函数)
req.onreadystatechange = function() {
// 当请求已经加载
if (req.readyState == 4) {
// 当请求返回成功
if (req.status == 200) { //或者 req.status < 400
// 当定义了成功回调函数时，执行成功回调函数
if (callback)
callback(req, data);
}
// 当请求返回错误
else {
//当定义了失败回调函数时，执行失败回调函数
if (callBackError)
callBackError(req, data);
}
// 有池的管理，我们可以省却释放资源的方法
// try {
// delete req;
// req = null;
// }
// catch (e) {
// alert(e.message);
// }
}
}
//如果以POST方式回发服务器
if (method.toUpperCase() == "POST") {
req.open("POST", url, true);
//请求是否需要缓存(只有在req.open之后才可以设置此项)
if (cached)
req.setRequestHeader("If-Modified-Since", "0");
//请求需要编码
if (urlencoded)
req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
req.send(data);
MyAjaxObj.reqList.push(req);
}
//以GET方式请求
else {
req.open("GET", url, true);
//请求是否需要缓存
if (cached)
req.setRequestHeader("If-Modified-Since", "0");
req.send(null);
MyAjaxObj.reqList.push(req);
}
return req;
}
//全部清除XMLHTTP数组元素，释放资源
MyAjaxObj.clearReqList = function() {
var len = MyAjaxObj.reqList.length;
for (var i = 0; i < len; i++) {
var req = MyAjaxObj.reqList[i];
if (req) {
try {
delete req;
} catch (e) { }
}
}
MyAjaxObj.reqList = [];
}
//进一步封装XMLHTTP以POST方式发送请求时的代码
//isClear：是否清除XMLHTTP数组的所有元素；其他参数的意义见 MyAjaxObj.send
MyAjaxObj.sendPost = function(url, data, callback, isClear, isCached, callBackError) {
if (isClear) {
MyAjaxObj.clearReqList();
}
MyAjaxObj.send(url, "POST", callback, data, true, isCached, callBackError); //post方法需要编码
}
//进一步封装XMLHTTP以GET方式发送请求时的代码
MyAjaxObj.sendGet = function(url, args, callback, isClear, isCached, callBackError) {
if (isClear)
MyAjaxObj.clearReqList();
return MyAjaxObj.send(url, "GET", callback, args, false, isCached, callBackError);
}
最后再ps：上周周末和一个哥们聊天的时候谈到ajax应用中的xmlhttp对象。那哥们ms很“虔诚”地问我说xmlhttp怎么就异步通信了。我当时竟然毫不思索地说因为这个对象处理我们的请求调用是“异步”的（当然可以设置成同步的，不过这是一句废话），当前这个请求不会影响其他的操作。这个回答是很“官方”的，显然没有说到问题的本质。哥们，您的眼神儿有必要那么bs人么？现在稍作分析，个人认为其实每个xmlhttp异步请求都会触发一个回调函数，这个回调函数的调用不影响其他的操作，这个方法才是“异步”。如果对比c#里的异步处理回调方法，它们在原理上其实是相通的。 哈哈，现在终于想通了， 真是太骄傲，太有出息了，想到就兴奋！
标签: javascript xmlhttp 对象池
⑻ cocos 性能优化方案求助
一.内存优化
1.内存泄漏
在最近的项目中使用了C11的智能指针，经过一年的使用证明这是不是一个成功的选择。虽然已经没了自己管理的烦躁，但是增加了内存泄漏的几率。毕竟不是所有人都能完全理解和掌握shared_ptr的使用。 建议使用cocos2dx自带的轻量级智能指针，采用了引用计数，并且没有了C11智能指针循环引用及其他使用容易导致引用计数异常的问题。
2.缓存（材质缓存，精灵帧缓存）管理
这里必须要引入过渡场景，用于removeunused的缓存，然后预加载下一个场景需要使用的资源。 并且cocos2dx提供了api可以查看内存中所有的缓存，做为开发必须能完全熟知内存中的这些缓存，能及时判断哪些材质是多余的。
这里要多提的一点是，不使用jpg，android使用pkm，ios使用pvr是非常有必要的。特别对于8000*8000超大地图。
3.高性能对象池
传统对象池只有一个list保存所有对象，每次使用循环遍历查找未使用的对象。
这里的优化是新增一个队列保存所有可使用的对象。每次对象使用完进行push_front的操作，每次使用通过pop_front获取。
二.CPU优化
1.近似数学函数
开方、三角函数近似替换算法，计算两点间的距离（曼哈顿距离、牛顿迭代或者使用平方数值做比较），位移运算（针对频繁的乘除2的n次幂）等。
2.算法
在算法的选择上其实渗透在我们的每一个即使非常小的功能模块，对于不是专门研究算法的我们，算法更多是一种意识。拒绝所有的时间复杂度O（n*n）的操作，永不高估CPU的计算性能，在现有的操作上力求更低的计算量。 然后有的放矢的去选择适合自己项目的算法。
3.分帧
分帧是比较坏的情况，因为这时候优化可能到了末尾。确实有一些cpu密集型的计算需要分帧甚至开线程来解决了。
PS：空间换时间。其实上面三条包括我的高性能的高斯模糊算法那篇文章，基本上对于cpu的优化核心都是空间换时间。
三.GPU优化（Drawcall优化）
1.超大图的切片
切片太小对于drawcall是非常有影响的，目前使用最大化切片2048*2048，并且图片使用压缩格式使用存在于缓存中。
2.合图（多摄像机场景）
对于摄像机比较多的场景，由于底层是遍历摄像机，每个摄像机执行一次场景的全部绘制。
所以在合图的时候需要按照摄像机来分层合图，不要把不同摄像机的图片合到一起。
做为开发要能够根据看到的场景预估drawcall数量，在判断出异常的时候分步优化层级drawcall数量。
⑼ Integer 的常量缓存池
Integer中有个静态内部类IntegerCache，里面有个cache[],也就是Integer常量池，常量池的大小为一个字节（-128~127）
Byte，Short，Long 的缓存池范围默认都是: -128 到 127。可以看出，Byte的所有值都在缓存区中，用它生成的相同值对象都是相等的。
所有整型（Byte，Short，Long）的比较规律与Integer是一样的。