一、Eclipse编译器提供源代码格式输入
Eclipse提供自动源码格式选项，并且组织输入（删除未使用的代码）。你可以使用下面的这些快捷键进行操作。
Ctrl + Shift + F——源代码格式
Ctrl + Shift + O——组织输入并删除未使用的代码
代替手动调用这两个函数，只需根据Eclipse自动格式和自动组织选项，可以随时保存文件。
操作步骤，在Eclipse中进入Window -> Preferences -> Java -> Editor -> Save Actions，然后以选定的方式保存，最后检查Format source code + Organize imports。
___________________________________________________________________________________________________________________
http://www.cnblogs.com/hoojo/archive/2011/06/02/2068665.html
【MongoDB for Java】Java操作MongoDB
http://www.cnblogs.com/hoojo/archive/2011/06/01/2066426.html
http://www.cnblogs.com/hoojo/archive/2012/02/17/2355384.html
有人说，实践敏捷的根本不在于敏捷本身，而在于理解敏捷背后拥抱变化的基因。确实，使用敏捷，那么你就应该知道为何敏捷。
当你从某个行业去领悟衍生出这种方式，毕竟那是成熟行业成功的经验映射。在实际的操作中，分配，转型，时间，技能等等都需要严格谨慎的执行。
单纯的照搬模式并适合每个团队，况且你得允许人家吸纳敏捷开发的优势为己用，然后找到适合自身团队的敏捷开发方法。关键就在这个适合自身上，每个团队在敏捷的过程当中，摸索的过程都是不一样的，执行的人也不一样，这注定不会使每个团队都有相同的敏捷模式。
英特尔发布Intel Distribution for Apache Hadoop，这是名字听上去不太时髦，但是原因很明显。英特尔希望从芯片层面搭建Hadoop，提升计算速度和安全性。现在至强处理器支持Hadoop Distributed File System，英特尔宣称，它的处理器时间从原来的4个小时缩短到7分钟。
偶然在programmers.stackexchange.com 上看到了这个有趣的问题，有人问：既然普遍认为编程是比较难的工作，为什么业务分析人员和项目经理们会拿比程序员更多的薪水？虽然大多数的时候程序员都被发现是最晚离开公司的人，可那些家伙的工作却能拿更多的报酬，为什么会这样？
所以，要么是你的项目经理或业务分析员对公司更有价值，要么就是他们有更多的讨价还价的资本。我并不认为是前一种情况，也就是说，应该是后一种情 况。善于人际交往的人很少。这种事情也不能外包——因为他们需要接触客户。他们的相对稀缺给了他们更多讨价的资本，所以他们有了更高的报酬。
mongoDB：
db.dropDatabase() 删除当前库
db.user.drop(); 删除当前库中的表
show dbs 显示 当前所有库
可转载美文
http://blog.csdn.net/headman/article/details/4086648
http://ifeve.com/java-concurrency-thread-directory/ 多线程 主站
尽管面临很多挑战，多线程有一些优点使得它一直被使用。这些优点是：
- 资源利用率更好
- 程序设计在某些情况下更简单
- 程序响应更快
在单线程应用程序中，如果你想编写程序手动处理上面所提到的读取和处理的顺序，你必须记录每个文件读取和处理的状态。相反，你可以启动两个线程，每个线程处理一个文件的读取和操作。线程会在等待磁盘读取文件的过程中被阻塞。在等待的时候，其他的线程能够使用CPU去处理已经读取完的文件。其结果就是，磁盘总是在繁忙地读取不同的文件到内存中。这会带来磁盘和CPU利用率的提升。而且每个线程只需要记录一个文件，因此这种方式也很容易编程实现。
也就是说 每个线程只需要关注自己的工作 就可以了。
更快的意思 就是 不回去浪费cpu的资源。
设计更复杂
上下文切换的开销
当CPU从执行一个线程切换到执行另外一个线程的时候，它需要先存储当前线程的本地的数据，程序指针等，然后载入另一个线程的本地数据，程序指针等，最后才开始执行。这种切换称为“上下文切换”(“context switch”)。CPU会在一个上下文中执行一个线程，然后切换到另外一个上下文中执行另外一个线程。
上下文切换并不廉价。如果没有必要，应该减少上下文切换的发生。
增加资源消耗
线程在运行的时候需要从计算机里面得到一些资源。除了CPU，线程还需要一些内存来维持它本地的堆栈。它也需要占用操作系统中一些资源来管理线程。我们可以尝试编写一个程序，让它创建100个线程，这些线程什么事情都不做，只是在等待，然后看看这个程序在运行的时候占用了多少内存。
一个线程：
1 | Tread thread = new Thread(); |
执行该线程可以调用该线程的start()方法:
1 | thread.start(); |
第二种编写线程执行代码的方式是新建一个实现了java.lang.Runnable接口的类的实例，实例中的方法可以被线程调用。下面给出例子：
1 | public class MyRunnable implements Runnable { |
2 | public void run(){ |
3 | System.out.println("MyRunnable running"); |
4 | } |
5 | } |
为了使线程能够执行run()方法，需要在Thread类的构造函数中传入 MyRunnable的实例对象。示例如下：
1 | Thread thread = new Thread(new MyRunnable()); |
2 | thread.start(); |
当线程运行时，它将会调用实现了Runnable接口的run方法。上例中将会打印出”MyRunnable running”。
同样，也可以创建一个实现了Runnable接口的匿名类，如下所示：
1 | Runnable myRunnable = new Runnable(){ |
2 | public void run(){ |
3 | System.out.println("Runnable running"); |
4 | } |
5 | } |
6 | Thread thread = new Thread(myRunnable); |
7 | thread.start(); |
创建子类还是实现Runnable接口？
对于这两种方式哪种好并没有一个确定的答案，它们都能满足要求。就我个人意见，我更倾向于实现Runnable接口这种方法。因为线程池可以有效的管理实现了Runnable接口的线程，如果线程池满了，新的线程就会排队等候执行，直到线程池空闲出来为止。而如果线程是通过实现Thread子类实现的，这将会复杂一些。
有时我们要同时融合实现Runnable接口和Thread子类两种方式。例如，实现了Thread子类的实例可以执行多个实现了Runnable接口的线程。一个典型的应用就是线程池。
线程名
当创建一个线程的时候，可以给线程起一个名字。它有助于我们区分不同的线程。例如：如果有多个线程写入System.out，我们就能够通过线程名容易的找出是哪个线程正在输出。例子如下：
1 | MyRunnable runnable = new MyRunnable(); |
2 | Thread thread = new Thread(runnable, "New Thread"); |
3 | thread.start(); |
4 | System.out.println(thread.getName()); |
需要注意的是，因为MyRunnable并非Thread的子类，所以MyRunnable类并没有getName()方法。可以通过以下方式得到当前线程的引用：
1 | Thread.currentThread(); |
因此，通过如下代码可以得到当前线程的名字：
1 | String threadName = Thread.currentThread().getName(); |
死锁是两个或更多线程阻塞着等待其它处于死锁状态的线程所持有的锁。死锁通常发生在多个线程同时但以不同的顺序请求同一组锁的时候。
例如，如果线程1锁住了A，然后尝试对B进行加锁，同时线程2已经锁住了B，接着尝试对A进行加锁，这时死锁就发生了。线程1永远得不到B，线程2也永远得不到A，并且它们永远也不会知道发生了这样的事情。为了得到彼此的对象（A和B），它们将永远阻塞下去。这种情况就是一个死锁。
下面是本文讨论的主题：
1. Java中导致饥饿的原因：
- 高优先级线程吞噬所有的低优先级线程的CPU时间。
- 线程被永久堵塞在一个等待进入同步块的状态。
- 线程在等待一个本身也处于永久等待完成的对象(比如调用这个对象的wait方法)。
2. 在Java中实现公平性方案，需要:
- 使用锁，而不是同步块。
- 公平锁。
- 注意性能方面。
7830
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
