转自：http://www.cnblogs.com/xrq730/p/5060921.html
前言 Java多线程分类中写了21篇多线程的文章，21篇文章的内容很多，个人认为，学习，内容越多、越杂的知识，越需要进行深刻的总结，这样才能记忆深刻，将知识变成自己的。这篇文章主要是对多线程的问题进行总结的，因此罗列了40个多线程的问题。
这些多线程的问题，有些来源于各大网站、有些来源于自己的思考。可能有些问题网上有、可能有些问题对应的答案也有、也可能有些各位网友也都看过，但是本文写作的重心就是所有的问题都会按照自己的理解回答一遍，不会去看网上的答案，因此可能有些问题讲的不对，能指正的希望大家不吝指教。
转自：deeplearningbook-chinese 英文原版地址：deeplearningbook。GitHub上面的发布版本PDF文件存储在AWS S3上面，国内无法下载，因此拷贝了最新版本的放在此处：下载链接。
(5.00分 - 5票) 
Loading ... | 归档目录：算法数据结构 标签： deeplearning, 深度学习, 电子书 B树的定义，对于一个M阶的B树，有如下性质：
1、每个节点存储t个数值和t+1个子节点的索引。
2、根节点至少有[2, M]个子节点。即对于根节点，t的最大取值为M-1，如，5阶的B树，根节点最多有5个子节点。
3、非根非叶子节点，最多有M个子节点，M-1个数值。
2、非根非叶子节点，最少有M/2（向上取整）个子节点，M/2-1个数值。
4、叶子节点无索引，最多存储M-1个数值，最少存储M/2-1（向上取整）个数值。
5、所有叶子节点都处于同一深度。
如下图，是一个M=5的B-树。
前一阵子遇到一个奇怪的问题，分析了很久，最后查阅了一些资料，找到了问题的原因，是TCP的backlog机制的原因。首先描述一下重现问题的现象和过程： 构建一个TCP的服务端，监听端口4321，只监听请求，不accept，客户端不断发起连接，观察TCP连接建立的情况。服务端程序代码如下：
来北京出差有几周了，很久没更博客，写一篇记录下这次出差的一些感受。不知道为啥这次到北京跟上次去深圳的感觉不一样。上次去深圳是有一种变化特别大的感觉，无论是跟成都还是跟以前自己待了那么就的深圳比，有点不认识的感觉。深圳园区之间以前宽阔的马路，因为两边都立起了大树显得窄了很多，路面规整了很多，当然马蹄山还是老样子。可能是因为在那边呆了很多年有一点点变化就感觉变化特别大。而这次来北京，是第一次，居然没什么异样的感觉，也可能是节奏紧张，一下飞机，赶往办公区，晚饭还没吃，住处还没找，就开始写材料，开会讨论，也没有觉得特别生疏。接下来每天上班的感觉就跟在成都一样，甚至感觉不到是在千里之外的帝都上班，只在深夜下班到酒店时就会想着家人了。心态应该跟工作的内容有关系，做的是熟悉的内容，熟悉的模式，感觉不到差异，也可能是心态成熟了。
不满足于之前的树莓派搭建的HOME NAS，又折腾了一套X86的低功耗版NAS服务器，将之前放在硬盘盒里面的硬盘都规整到了NAS服务器内。直接安装Windows Server 2012版本，配置简单。
不断增加网络设备，突然发现家里的网络越来越复杂，首先把家里的网络设备连接图整理出来记录一下。
前文中对标记删除算法的介绍更多还是偏理论性质的。实践中，为了更好地满足现实的场景及需求，还需要对算法进行大量的调整。举个简单的例子，我们来看下JVM需要记录哪些信息才能让我们得以安全地分配对象空间。
JVM在清除不可达对象之后，还得确保它们所在的空间是可以进行复用的。对象删除会导致碎片的出现，这有点类似于磁盘碎片，这会带来两个问题：
问题排查除了最重要的解决思路和逻辑推导能力外，工具也是不可缺少的一部分，一个好用的工具可以事半功倍，甚至在某些情况下会因为没有相应的工具而压根就没法继续进行下去，这篇文章就来讲讲在排查Java问题时通常要用到的一些工具（:这种文章值得收藏，看一遍其实很容易忘）。
日志相关工具
查问题的时候会非常依赖日志，因此看日志的相关工具非常重要，通常的话掌握好tail,find,fgrep,awk这几个常用工具的方法就可以，说到这个就必须说关键的异常和信息日志输出是多么的重要（看过太多异常的随意处理，例如很典型的是应用自己的ServletContextListener实现，很多的Listener实现都会变成往外抛RuntimeException，然后直接导致tomcat退出，而tomcat这个时候也不会输出这个异常信息，这种时候要查原因真的是让人很郁闷，尽管也有办法）。
日志的标准化也非常重要，日志的标准化一方面方便像我这种要查各种系统问题的人，不标准的话连日志在哪都找不到；另一方面对于分布式系统而言，如果标准化的话是很容易做日志tracing的，对问题定位会有很大帮助。
