最近改了两个jAlbum的bug，问题并不复杂，但是比较有代表性。在这里记录一下。第一个问题是，在单张照片的页面提供了一个“隐藏”当前照片的按钮。当点击该按钮时，页面重新load，显示下一张照片，使用了当前照片的ID来构造下一张照片的url，即加载url：
/?next=[currentphotoid]&count=1，
具体到服务端接收这个请求时，需要使用当前照片的ID到数据库中索引下一张。
然后对当前照片发起删除操作，即使用ajax发起一个HTTP请求：
DELETE /photos/[currentphotoid]
向服务端发送一个delete请求，具体的浏览器端代码为：
标签归档： java
记录一下最近修改的两个Bug
Java 9 踩坑之启动参数
Java 9 出来一段时间了，也试着在Java 9 下运行jAlbum，原以为以Java一贯的向下兼容原则，应该都不用重新在JDK9编译，直接运行即可。然鹅，运行时报错，找不到类文件：
Java ThreadPoolExecutor线程池使用的一个误区
Java对多线程的封装非常丰富，提供了多种适用于不同场景的多并发实现。其中最基础，最核心的线程池要属ThreadPoolExecutor类了。该类有如下几个构造函数：
40个Java多线程问题总结
转自：http://www.cnblogs.com/xrq730/p/5060921.html
前言 Java多线程分类中写了21篇多线程的文章，21篇文章的内容很多，个人认为，学习，内容越多、越杂的知识，越需要进行深刻的总结，这样才能记忆深刻，将知识变成自己的。这篇文章主要是对多线程的问题进行总结的，因此罗列了40个多线程的问题。
这些多线程的问题，有些来源于各大网站、有些来源于自己的思考。可能有些问题网上有、可能有些问题对应的答案也有、也可能有些各位网友也都看过，但是本文写作的重心就是所有的问题都会按照自己的理解回答一遍，不会去看网上的答案，因此可能有些问题讲的不对，能指正的希望大家不吝指教。
Java中的垃圾回收
前文中对标记删除算法的介绍更多还是偏理论性质的。实践中，为了更好地满足现实的场景及需求，还需要对算法进行大量的调整。举个简单的例子，我们来看下JVM需要记录哪些信息才能让我们得以安全地分配对象空间。
碎片及整理（Fragmenting and Compacting）
JVM在清除不可达对象之后，还得确保它们所在的空间是可以进行复用的。对象删除会导致碎片的出现，这有点类似于磁盘碎片，这会带来两个问题：
Java问题排查工具箱
问题排查除了最重要的解决思路和逻辑推导能力外，工具也是不可缺少的一部分，一个好用的工具可以事半功倍，甚至在某些情况下会因为没有相应的工具而压根就没法继续进行下去，这篇文章就来讲讲在排查Java问题时通常要用到的一些工具（:这种文章值得收藏，看一遍其实很容易忘）。
日志相关工具
查问题的时候会非常依赖日志，因此看日志的相关工具非常重要，通常的话掌握好tail,find,fgrep,awk这几个常用工具的方法就可以，说到这个就必须说关键的异常和信息日志输出是多么的重要（看过太多异常的随意处理，例如很典型的是应用自己的ServletContextListener实现，很多的Listener实现都会变成往外抛RuntimeException，然后直接导致tomcat退出，而tomcat这个时候也不会输出这个异常信息，这种时候要查原因真的是让人很郁闷，尽管也有办法）。
日志的标准化也非常重要，日志的标准化一方面方便像我这种要查各种系统问题的人，不标准的话连日志在哪都找不到；另一方面对于分布式系统而言，如果标准化的话是很容易做日志tracing的，对问题定位会有很大帮助。
开源照片整理系统jAlbum 0.1.3版本发布
第三个版本，jAlbum完整版差不多完工了：https://github.com/shentar/jAlbum/releases/tag/jAlbum_0.1.3。
最后解决了文件系统监控的问题。利用Java1.7封装的文件系统的通知回调机制，实现对指定目录的递归监控，避免每次全盘扫描性能太低的问题。
注意对于linux系统对于单个用户能够监听的inotify对象个数做了限制，一般是限制为8192，因此需要修改系统内核的配置：在/etc/sysctl.conf文件中，新增一行：fs.inotify.max_user_watches=1000000，表明将该限制修改为100万个。下次重启后会生效，如果希望当前立即生效，则需要执行命令：sysctl –p 。
对于WatchService，只监控当前目录的变化，当前目录下新增文件或者文件夹时，当前文件夹会有修改事件或者创建事件，但是再下一层的文件夹或者文件发生变更时，并不会有任何事件，因此如果要监控指定的文件夹，需要递归监控到最后一层。没有验证文件系统的notify机制对进程性能和文件系统性能的影响，在树莓派上面简单验证了下，能够非常及时的发现新增文件，进程CPU和内存也没有明显的增加。终于解决了每次都有依赖全盘扫描一遍文件才能发现新增的文件的问题。
具体代码请参见源码中的DirWatchService类。
并发流程控制—CountDownLatch
假如有这样一个需求，当我们需要解析一个Excel里多个sheet的数据时，可以考虑使用多线程，每个线程解析一个sheet里的数据，等到所有的sheet都解析完之后，程序需要提示解析完成。
在这个需求当中要实现主线程等待所有线程完成sheet的解析操作，最简单的做法是使用join。代码如下：
| 
(4.75分 - 12票) 
Loading ... | 归档目录：Java, 多线程编程, 语言基础 同时打有标签：CountDownLatch, 并发编程
(4.75分 - 12票) 
Loading ... | 归档目录：Java, 多线程编程, 语言基础 同时打有标签：CountDownLatch, 并发编程 一周技术文章收集（6.27）
- 一站式学习Wireshark（五）：TCP窗口与拥塞处理
http://blog.jobbole.com/71925/ - Java类重新加载101：对象、类和类加载器
http://www.importnew.com/12198.html - The Swift Programming Language 中文版
http://numbbbbb.gitbooks.io/-the-swift-programming-language-/ - 关于寻路算法的一些思考（1）：A*算法介绍
http://blog.jobbole.com/71044/ - 译：复杂系统故障面面观
http://blog.liancheng.info/how-complex-systems-fail-zh/#.U61cP_mSzWg - 一些非常棒的在线工具
http://examplecode.github.io/tools/2014/06/21/frequently-online-tools/
Google Guava简介
看到Guava这个名字觉得有点怪怪的，于是搜索了一下，Google Java的合称。Guava工程包含了若干被Google的 Java项目广泛依赖 的核心库，例如：集合（collections）、缓存（caching）、原生类型支持（primitives support）、并发库 （concurrency libraries）、通用注解（common annotations）、字符串处理（string processing）、I/O 等等。 所有这些工具每天都在被Google的工程师应用在产品服务中。
项目信息
首页：https://code.google.com/p/guava-libraries/
并发编程网在对每一个主题的各个子类的介绍进行翻译并发表。这里转载目录。
| 
(4.13分 - 8票) Loading ... | 归档目录：Java, 语言基础 同时打有标签：Google Guava
(4.13分 - 8票) Loading ... | 归档目录：Java, 语言基础 同时打有标签：Google Guava 
