Wali Zh

Cookie和Session都是客户端与服务器之间保持状态的解决方案，具体来说，cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。 **(1). Cookie 及其相关 API ：** Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie，而客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器，服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。  **(2). Session 及其相关 API：** 同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该用户状态，就获取Session来保存状态，这时，如果服务器已经为此客户端创建过session，服务器就按照sessionid把这个session检索出来使用；如果客户端请求不包含sessionid，则为此客户端创建一个session并且生成一个与此session相关联的sessionid，并将这个sessionid在本次响应中返回给客户端保存。保存这个sessionid的方式可以采用 cookie机制 ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；若浏览器禁用Cookie的话，可以通过 URL重写机制 将sessionid传回服务器。  (3). Session 与 Cookie 的对比： - 实现机制：Session的实现常常依赖于Cookie机制，通过Cookie机制回传SessionID； - 大小限制：Cookie有大小限制并且浏览器对每个站点也有cookie的个数限制，Session没有大小限制，理论上只与服务器的内存大小有关； - 安全性：Cookie存在安全隐患，通过拦截或本地文件找得到cookie后可以进行攻击，而Session由于保存在服务器端，相对更加安全； -...

一旦一个共享变量（类的成员变量、类的静态成员变量）被 volatile修饰之后，那么就具备了两层语义： 1）保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。 2）禁止进行指令重排序。 volatile 本质是在告诉jvm 当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取； synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。 1.volatile 仅能使用在变量级别； synchronized则可以使用在变量、方法、和类级别的 2.volatile 仅能实现变量的修改可见性，并不能保证原子性； synchronized则可以保证变量的修改可见性和原子性 3.volatile 不会造成线程的阻塞； synchronized可能会造成线程的阻塞。 4.volatile 标记的变量不会被编译器优化； synchronized标记的变量可以被编译器优化

1. TCP 对应的应用层协议： - FTP：定义了文件传输协议，使用21端口。常说某某计算机开了FTP服务便是启动了文件传输服务。下载文件，上传主页，都要用到FTP服务。 - Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于DOS模式下的通信服务。如以前的BBS是-纯字符界面的，支持BBS的服务器将23端口打开，对外提供服务。 - SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么SMTP端口设置这个栏，服务器开放的是25号端口。 - POP3：它是和SMTP对应，POP3用于接收邮件。通常情况下，POP3协议所用的是110端口。也是说，只要你有相应的使用POP3协议的程序（例如Fo-xmail或Outlook），就可以不以Web方式登陆进邮箱界面，直接用邮件程序就可以收到邮件（如是163邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。 - HTTP：从Web服务器传输超文本到本地浏览器的传送协议。 2.UDP 对应的应用层协议： - DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口。 - SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。 - TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务。  

------------------------------------------ Bitamp 占用内存大小 = 宽度像素 x （inTargetDensity / inDensity） x 高度像素 x （inTargetDensity / inDensity）x 一个像素所占的内存 注：这里inDensity表示目标图片的dpi（放在哪个资源文件夹下），inTargetDensity表示目标屏幕的dpi，所以你可以发现inDensity和inTargetDensity会对Bitmap的宽高 进行拉伸，进而改变Bitmap占用内存的大小。 在Bitmap里有两个获取内存占用大小的方法。 - getByteCount()：API12 加入，代表存储 Bitmap 的像素需要的最少内存。 - getAllocationByteCount()：API19 加入，代表在内存中为 Bitmap 分配的内存大小，代替了 getByteCount()...

“三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。 - 正常的情况：A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B。没有 “已失效的连接请求报文段”。 - 现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就向 A 发出确认报文段，同意建立连接。 假设不采用“三次握手”，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但...

内存缓存基于LruCache实现，磁盘缓存基于DiskLruCache实现。这两个类都基于Lru算法和LinkedHashMap来实现。 LRU算法可以用一句话来描述，如下所示： - LRU是Least Recently Used的缩写，最近最久未使用算法，从它的名字就可以看出，它的核心原则是如果一个数据在最近一段时间没有使用到，那么它在将来被 访问到的可能性也很小，则这类数据项会被优先淘汰掉。 LruCache的原理是利用LinkedHashMap持有对象的强引用，按照Lru算法进行对象淘汰。具体说来假设我们从表尾访问数据，在表头删除数据，当访问的数据项在链表中存在时，则将该数据项移动到表尾，否则在表尾新建一个数据项。当链表容量超过一定阈值，则移除表头的数据。 为什么会选择LinkedHashMap呢？ 这跟LinkedHashMap的特性有关，LinkedHashMap的构造函数里有个布尔参数accessOrder，当它为true时，LinkedHashMap会以访问顺序为序排列元素，否则以插入顺序为序排序元素。 DiskLruCache与LruCache原理相似，只是多了一个journal文件来做磁盘文件的管理，如下所示： ``` libcore.io.DiskLruCache 1 1 1 DIRTY 1517126350519 CLEAN 1517126350519 5325928 REMOVE 1517126350519 ``` 注：这里的缓存目录是应用的缓存目录/data/data/pckagename/cache，未root的手机可以通过以下命令进入到该目录中或者将该目录整体拷贝出来： ``` //进入/data/data/pckagename/cache目录 adb shell run-as...

Tips:HashMap 本身就是不可排序的，但是该道题偏偏让给HashMap排序，那我们就得想在API 中有没有这样的Map 结构是有序的，LinkedHashMap，对的，就是他，他是Map 结构，也是链表结构，有序的，更可喜的是他是HashMap 的子类，我们返回LinkedHashMap即可.    但凡是对集合的操作，我们应该保持一个原则就是能用JDK中的API就用JDK中的API，比如排序算法我们不应该 去 用 冒 泡 或 者 选 择 ， 而 是 首 先 想 到 用 Collections 集 合 工 具 类 。...

    在java中有普通集合、同步（线程安全）的集合、并发集合。普通集合通常性能最高，但是不保证多线程的安全性和并发的可靠性。线程安全集合仅仅是给集合添加了 synchronized 同步锁，严重牺牲了性能，而且对并发的效率就更低了，并发集合则通过复杂的策略不仅保证了多线程的安全又提高的并发时的效率。 参考阅读：   ConcurrentHashMap 是线程安全的HashMap的实现，默认构造同样有initialCapacity 和loadFactor属性，不过还多了一个 concurrencyLevel属性，三属性默认值分别为16、0.75 及 16。其内部使用锁分段技术，维持这锁Segment的数组，在Segment数组中又存放着Entity[]数组，内部hash算法将数据较均匀分布在不同锁中。 put操作：     并没有在此方法上加上synchronized，首先对key.hashcode进行hash 操作，得到key的hash 值。hash 操作的算法和 map 也不同，根据此 hash 值计算并获取其对应的数组中的 Segment 对象(继承自ReentrantLock)，接着调用此Segment对象的put方法来完成当前操作。     ConcurrentHashMap 基于concurrencyLevel划分出了多个Segment 来对key-value进行存储，从而避免每次put操作都得锁住整个数组。在默认的情况下，最佳情况下可允许16 个线程并发无阻塞的操作集合对象，尽可能地减少并发时的阻塞现象。 get(key):      首先对key.hashCode进行hash 操作，基于其值找到对应的Segment 对象，调用其get方法完成当前操作。而 Segment...

答：整个的因特网就是一个单一的、抽象的网络。IP 地址就是给因特网上的每一个主机（或路由器）的每一个接口分配一个在全世界范围是唯一的 32 位标识符，它是一个逻辑地址，用以屏蔽掉物理地址的差异。IP地址编址方案将IP地址空间划分为A、B、C、D、E五类，其中A、B、C是基本类，D、E类作为多播和保留使用，为特殊地址。 每个IP地址包括两个标识码（ID），即网络ID和主机ID。同一个物理网络上的所有主机都使用同一个网络ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。A~E类地址的特点如下： - A类地址：以0开头，第一个字节范围：0~127； - B类地址：以10开头，第一个字节范围：128~191； - C类地址：以110开头，第一个字节范围：192~223； - D类地址：以1110开头，第一个字节范围为224~239； - E类地址：以1111开头，保留地址  **1). A类地址：1字节的网络地址 + 3字节主机地址，网络地址的最高位必须是“0”** 一个A类IP地址是指， 在IP地址的四段号码中，第一段号码为网络号码，剩下的三段号码为本地计算机的号码。如果用二进制表示IP地址的话，A类IP地址就由1字节的网络地址和3字节主机地址组成，网络地址的最高位必须是“0”。A类IP地址中网络的标识长度为8位，主机标识的长度为24位，A类网络地址数量较少，有126个网络，每个网络可以容纳主机数达1600多万台。 A类IP地址的地址范围1.0.0.0到127.255.255.255（二进制表示为：00000001 00000000 00000000 00000000 - 01111110 11111111 11111111...

Android的进程主要分为以下几种： #### 前台进程 用户当前操作所必需的进程。如果一个进程满足以下任一条件，即视为前台进程： - 托管用户正在交互的 Activity（已调用 Activity 的 onResume() 方法） - 托管某个 Service，后者绑定到用户正在交互的 Activity - 托管正在“前台”运行的 Service（服务已调用 startForeground()） - 托管正执行一个生命周期回调的 Service（onCreate()、onStart() 或 onDestroy()） - 托管正执行其 onReceive() 方法的 BroadcastReceiver 通常，在任意给定时间前台进程都为数不多。只有在内存不足以支持它们同时继续运行这一万不得已的情况下，系统才会终止它们。...