Java防SQL注入，最简单的办法是杜绝SQL拼接，SQL注入攻击能得逞是因为在原有SQL语句中加入了新的逻辑，如果使用PreparedStatement来代替Statement来执行SQL语句，其后只是输入参数，SQL注入攻击手段将无效，这是因为PreparedStatement不允许在不同的插入时间改变查询的逻辑结构，大部分的SQL注入已经挡住了，在WEB层我们可以过滤用户的输入来防止SQL注入比如用Filter来过滤全局的表单参数。

　　也可以单独在需要防范SQL注入的JavaBean的字段上过滤：

在Java中有两类线程：用户线程（UserThread）、守护线程（DaemonThread）。

　　所谓守护线程，是指在程序运行的时候在后台提供一种通用服务的线程，比如垃圾回收线程就是一个很称职的守护者，并且这种线程并不属于程序中不可或缺的部分。因此，当所有的非守护线程结束时，程序也就终止了，同时会杀死进程中的所有守护线程。反过来说，只要任何非守护线程还在运行，程序就不会终止。

　　用户线程和守护线程两者几乎没有区别，唯一的不同之处就在于虚拟机的离开：如果用户线程已经全部退出运行了，只剩下守护线程存在了，虚拟机也就退出了。因为没有了被守护者，守护线程也就没有工作可做了，也就没有继续运行程序的必要了。

　　将线程转换为守护线程可以通过调用Thread对象的setDaemon(true)方法来实现。在使用守护线程时需要注意一下几点：

　　（1）thread.setDaemon(true)必须在thread.start()之前设置，否则会跑出一个IllegalThreadStateException异常。你不能把正在运行的常规线程设置为守护线程。

　　（2）在Daemon线程中产生的新线程也是Daemon的。

　　（3）守护线程应该永远不去访问固有资源，如文件、数据库，因为它会在任何时候甚至在一个操作的中间发生中断。

　　代码示例：

import java.util.concurrent.TimeUnit;   /**  * 守护线程  */  public class Daemons {   /**  * @param args  * @throws InterruptedException   */  public static void main(String[] args) throws InterruptedException {   Thread d = new Thread(new Daemon());   d.setDaemon(true); //必须在启动线程前调用  d.start();   System.out.println("d.isDaemon() = " + d.isDaemon() + ".");   TimeUnit.SECONDS.sleep(1);   }   }   class DaemonSpawn implements Runnable {   public void run() {   while (true) {   Thread.yield();   }   }   }   class Daemon implements Runnable {   private Thread[] t = new Thread[10];   public void run() {   for (int i=0; i<t.length; i++) {   t[i] = new Thread(new DaemonSpawn());   t[i].start();   System.out.println("DaemonSpawn " + i + " started.");   }   for (int i=0; i<t.length; i++) {   System.out.println("t[" + i + "].isDaemon() = " +   t[i].isDaemon() + ".");   }   while (true) {   Thread.yield();   }   }   }

　　运行结果：

d.isDaemon() = true.   DaemonSpawn 0 started.   DaemonSpawn 1 started.   DaemonSpawn 2 started.   DaemonSpawn 3 started.   DaemonSpawn 4 started.   DaemonSpawn 5 started.   DaemonSpawn 6 started.   DaemonSpawn 7 started.   DaemonSpawn 8 started.   DaemonSpawn 9 started.   t[0].isDaemon() = true.   t[1].isDaemon() = true.   t[2].isDaemon() = true.   t[3].isDaemon() = true.   t[4].isDaemon() = true.   t[5].isDaemon() = true.   t[6].isDaemon() = true.   t[7].isDaemon() = true.   t[8].isDaemon() = true.   t[9].isDaemon() = true.

　以上结果说明了守护线程中产生的新线程也是守护线程。

　　如果将mian函数中的TimeUnit.SECONDS.sleep(1);注释掉，运行结果如下：

d.isDaemon() = true.   DaemonSpawn 0 started.   DaemonSpawn 1 started.   DaemonSpawn 2 started.   DaemonSpawn 3 started.   DaemonSpawn 4 started.   DaemonSpawn 5 started.   DaemonSpawn 6 started.   DaemonSpawn 7 started.   DaemonSpawn 8 started.   DaemonSpawn 9 started.

　　以上结果说明了如果用户线程已经全部退出运行了，只剩下守护线程存在了，虚拟机也就退出了。下面的例子也说明了这个问题。

　　代码示例：

import java.util.concurrent.TimeUnit;   /**   * Finally shoud be always run ?   */   public class DaemonsDontRunFinally {   /**   * @param args   */   public static void main(String[] args) {   Thread t = new Thread(new ADaemon());   t.setDaemon(true);   t.start();   }   }   class ADaemon implements Runnable {   public void run() {   try {   System.out.println("start ADaemon...");   TimeUnit.SECONDS.sleep(1);   } catch (InterruptedException e) {   System.out.println("Exiting via InterruptedException");   } finally {   System.out.println("This shoud be always run ?");   }   }   }

　　运行结果：

　　start ADaemon...

　　如果将main函数中的t.setDaemon(true);注释掉，运行结果如下：

　　start ADaemon...

　　This shoud be always run ?

组织beta测试的十二个最高秘诀

　这篇文章中，作者以诚恳的笔触将自己在组织beta测试的亲身感受与大家分享，希望可以给广大开发人员带来帮助。

　　下面是一些关于如何组织一次软件的beta测试的秘诀。需要注意的是，这里所说的“软件”指的是面向大量用户的软件，也就是我所称的“包装盒软件（注：“包装盒软件”指的是在商场中上架销售、有独立包装、外面用热收缩塑料膜密封的软件商品。）”（shrink-wrap）。这些秘诀对商业项目和开源项目都适用。不管你开发软件的目的是获得报酬，还是获得眼球效应，或是提高在同行中的知名度，都可以参考这些秘诀。但是，我关注的只是有大量用户的软件产品，而不是公司内部的IT项目。

　　1. 开放式的beta测试是没用的。要是你那样做，只可能有两种结果。一种结果是你有太多的测试者（就像Netscape那样），这些人向你反馈了大量的意见，你从中根本不可能得到有用的数据。另一种结果是，现有的测试者根本不向你反馈他们的使用情况，导致你无法得到足够的数据。

　　2. 要想找到那些能够向你反馈意见的测试者，最好的方法是诉诸他们“言行一致”的心理。你需要让他们自己承诺会向你发送反馈意见，或者更好的方法是，让他们自己申请参加beta测试。一旦他们采取了某些主动行为，比如填写一张申请表，在“我同意尽快发回反馈意见和软件故障报告”的选项上打勾，许多人就会发送反馈意见，因为他们想要“言行一致”。

　　3. 不要妄想一次完整的beta测试的所有步骤能够在少于8-10周的时间内完成。我曾经试过，结果是除非老天帮忙，否则根本不可能做到。

　　4. 不要妄想在测试中发布新的软件版本的频率能够快于每两周一次。我曾经试过，结果是除非老天帮忙，否则根本不可能有效。

　　5. 一次beta测试中计划发布的软件版本不要少于4个。我从来没试过少于4个版本，因为太明显了，那样不可能达到测试目的。

　　6. 如果在测试过程中你为软件添加了一个功能，那么哪怕这个功能非常微小，整个8个星期的测试也要回到起点，从头来过，而且你还需要再发布3个或4个新版本。我犯过的最大错误之一就是，在CityDesk 2.0的beta测试接近尾声的时候，我向软件中加入了一些保留空格的代码，这产生了一些意想不到的副作用（如果我们可以这样说），测试的时间不够了，我本应该将测试时间加长、进一步收集数据的。

　　7. 即使你有一个申请参加beta测试的步骤，最后也只有五分之一的测试者会向你提交反馈意见。

　　8. 我们制定了一条政策，所有向我们提交反馈意见的测试者都将免费获赠一份正版软件。不管你的反馈意见是正面的，还是负面的，只要你提交给我们，就能获得赠品。但是，在测试结束的时候，那些不提交反馈意见的测试者什么也不会得到。

　　9. 你需要的严肃测试者（即那些会把反馈意见写成3页纸发送给你的人）的最小数量大约是100人左右。如果你独立开发软件，那么这是你能够处理的反馈意见的最大数量。如果你有一支测试管理团队或专门的beta测试经理，那么设法分别为每个处理反馈意见的人找到100个严肃测试者。

　　10. 根据第7条，即使你有一个参加beta测试的申请步骤，最后也只有五分之一的测试者会真地使用你的产品并将反馈意见发送给你。那么，假定你有一个质量控制部门，里面一共有3个测试管理人员，这就意味着你必须批准1500份参加beta测试的申请表，因为这样才能产生300个严肃测试者。批准的数量少于这个数目的话，你就不会得到充分的反馈意见；批准的数量多于这个数目的话，你就会被许许多多重复的反馈意见淹没。

　　11. 大多数beta测试的参与者只是在第一次拿到这个程序的时候才会去试用一下，然后就丧失了兴趣。此后每次你推出一个新的版本并发送给他们，他们也不会有兴趣重新测试它。除非他们每天都在用这个程序，但是对于大多数人来说，这是不可能的。因此，你需要错开不同版本的测试对象，将你的所有beta测试参与者分成四组，每次发布一个新版本的时候，就把一个新的组加入测试，这样就能保证每个版本都有第一次使用这个程序的测试者。

　　12. 不要混淆技术beta和市场beta。我上面谈的这些都是针对技术beta，它的目标是发现软件中的错误和得到及时的用户反馈意见。市场beta则是软件正式发布前的预览版本，对象主要是新闻媒体、大客户和那些写入门教程的家伙（该教程必须在软件上市的同一天问世）。对于市场beta，你的目的并不是得到反馈意见。（虽然无论你怎么做，那些写书的家伙很可能都会滔滔不绝地告诉你一大堆意见。如果你置之不理，这些意见就会被复制粘贴进他们自己的书里。）

数据库加密领域的五个最差实践

　薄弱的加密措施让数据库关键信息面临更多风险。数据库加密对于关键数据的存储安全性有着巨大的意义，但这种积极意义产生的前提是首先将加密工作做好。随着数据库加密部署情况的日益增多，部署效果自然也随之变得良莠不齐。以下五类数据库加密部署是专家组们公认的最差实践方式。为了获得最理想的安全效益，我们应该尽量避免如下几类操作失误。

　　1、将密钥保存在错误的地方

　　据安全专家称，很多人习惯于将加密的数据和密钥一起存放，这称得上是数据库加密工作中的原罪之一。

　　“如果你在你的数据库中加密敏感信息，那么千万不要把加密密钥或者认证证书同与之相关加密数据存储在一起。”电气行业首席安全工程师Luther Martin说道，“一旦发生这种情况，虽然感觉上加密信息是安全的，其实整套体系已经失去了实际意义。”

　　若想真正地保护好数据，要将密钥妥善地加以管理；应把它与加密数据、敏感信息密钥之类，各自区分并存放。

　　2、密钥未能集中管理

　　由于很多企业自身的安保机制较为薄弱，因此随意将密钥保存在防范措施不足的地方也就比较常见。

　　“关键问题在于在企业内部，使用大量密钥和数字签证的情况广泛存在”，Venafi的CEO Jeff Hudson说，“研究表明，企业中所管理的认证及密钥系统少则上千、多则上万的现象非常普遍。”

　　很多厂商都销售加密产品，却没有向客户教授相应的管理应用知识，Hudson说。

　　“加密技术只是解决方案的一半。IT部门必须掌握监控密钥并需要了解都谁有权使用密钥。为了维护整个企业的利益，快速为密钥部署妥善的保护机制可谓至关重要，”他说。“为了严格贯彻访问控制，职责分离以及策略改善制度，大家需要对自动化监控密钥和证书管理工作加深理解。”

　　理论上，为了了解本地密钥在哪里以及保护这些密钥的具体方案，企业应当尽可能地集中管理密钥。

　　3、依靠自创的方案

　　IT人士最怕的就是客户自己搞出一套自创系统，借以节约成本。但他们的利己意识倒不一定是坏事，因为除非你的员工都是具有多年经验的密码专家，否则轻易使用自制的加密方案或者密钥管理系统简直就是自掘坟墓。

　　“失败的自主开发数据库加密密钥管理方案的部署，会迫使那些主要经营零售业的厂商转型为专业型供应商” Protegrity公司的CTO Ulf Mattsson说：“这看起来非常容易但实际上相当危险。”

　　4、缺乏备份资料加密机制

　　如果你只对数据库进行加密，而不对相关数据的备份加以同样的保护，也会让你的企业陷入风险当中。

　　“在我们生活的时代里，磁带落在后备厢里，笔记本丢了等等所有意外情况都不能成为我们的借口，” 403网络安全CEO Alan Wlasuk说“为所有数据库的备份资料进行加密是一件理所当然的事。”

　　“即使表面上看来毫无价值，也要以00加密格式备份所有数据库内容，”他说“数据备份最终会存储在一个意想不到的地方，如果你知道他们是安全的，你也就可以高枕无忧了。”

　　5、使用过时的加密算法

　　在去年11月Gawker遭受的重创中，部分原因就是密码信息惨遭泄露，这些密码被几十年未更新过的陈旧加密技术保护着。而这一情况并非特例。许多企业都需要对数据进行加密，但使用的却是超级老旧的加密方式，这简直像是在用纸做的盔甲来保护自己的身体。

　　“多年前使用的中古加密技术系统早就扛不住了” Wlasuk说。企业不仅仅要留心加密数据库，同样要关注哪些加密技术已经过时、并迫切需要新的加密算法补充进来。

1、脚本说明

　　此脚本用于清空数据库数据，只删除相关表记录，保留表结构及存储过程触发器等主要架构。

　　设计思路：

　　1）根据表添加时间逆向获取所有用户表信息

　　2）使用游标循环删除每张表内数据

　　3）使用delete进行删除，即使有外键关系同样可以删除表记录

　　4）表存在自增主键则将其重置为0

　　5）截断日志，将数据库表空间及日志文件缩减到最小

　　2、使用说明

　　1）建立删除数据库存储过程SP_DaTaBaSeClear

　　2）执行该存储过程，执行过程中查看执行信息，如有红色信息则先手动删除红色信息表记录

　　-- 执行存储过程删除表数据

　　EXEC SP_DaTaBaSeClear

　　3）如仍然报出红色信息则直接执行以下语句进行删除

　　4）最后执行脚本重置数据库大小

1、查看当前可用的所有环境变量（＝系统变量＋用户变量）

　　set

　　查看某个环境变量，如PATH

　　set PATH

　　添加环境变量，如xxx=aa

　　set xxx=aa

　　将环境变量（如xxx）的值置为空

　　set xxx=

　　在某个环境变量（如PATH）后添加新的值（如d:\xxx）

　　set PATH=%PATH%;d:\xxx

　　[注]：以命令行方式对环境变量的操作只对当前窗口的应用有效！

　　2、Windows下JAVA用到的环境变量主要有3个：JAVA_HOME、CLASSPATH、PATH。

　　1）JAVA_HOME指向的是JDK的安装路径，如x:\ j2sdk1.4.2，在这路径下你应该能够找到bin、lib等目录。设置方法：JAVA_HOME=c:\ j2sdk1.4.2

　　2）PATH变量的作用

　　java程序在运行时首先在path变量所定义的路径去找java.exe，并以最先找到的为准，如果安装完j2sdk后不加设置，一般是C:\WINDOWS\system32目录。

　　j2sdk1.4（还有其它java开发工具如jbuilder8）在安装后会将java.exe拷贝到C:\WINDOWS\system32目录下，当执行java.exe时，需要装载这个SDK下的一些文件。

　　如j2sdk1.4在安装完成后，C:\WINDOWS\system32下的java.exe在运行时会在C:\Program File\java\目录下装载必需的一些文件。但安装j2sdk后一般会在PATH变量的最前面设置C:\ j2sdk1.4.2 \bin。

　　当先安装j2sdk1.4.2，后安装jbuilder8等开发工具时，由于jbuilder8的java.exe在拷贝到C:\WINDOWS\system32时可能覆盖了j2sdk1.4.2的java.exe，那么这时在运行的java.exe会到jbuilder8所在的目录去装载必需的一些文件。

　　3）CLASSPATH环境变量的作用

　　告诉类装载器到哪里去寻找第三方提供的类和用户定义的类。也可用使用JVM命令行参数-classpath分别为应用程序指定类路径，在－classpath中指定的类路径覆盖CLASSPATH环境变量中指定的值。

　　3、当机器内装有多个SDK版本时，如何查看所用的是哪个SDK？

　　java -verbose

　　在出现的屏幕信息中可以看出系统装载的是哪个目录下的文件。

　　4、Windows OS下设置PATH的方法

　　〔系统〕->〔环境〕-> 〔高级〕，在PATH变量的文本框中的最前面输入C:\ j2sdk1.4.2\bin

　　或在命令行窗口中执行 set path=c:\j2sdk1.4.2\bin;%path%; 这样在命令行窗口的任一路径下都可以执行java.exe程序了。或设置PATH=%JAVA_HOME%\bin;%PATH%

　　5、对于CLASSPATH环境变量的设置方法要加倍小心，是因为以后你出现的莫名其妙80%以上的怪问题都可能是由于CLASSPATH设置不对引起的

　　CLASSPATH=.\;%JAVA_HOME%\lib\tools.jar

　　首先要注意的是最前面的".\;"，——句点反斜杠分号。这个是告诉JDK，搜索CLASS时先查找当前目录的CLASS文件。

　　【Troubleshooting】

　　编译会出现以下情况，看你是否真得都理解环境变量的设置，并能解决它。

　　[T1] error：java不是一个可运行的程序？ 由于没有设置环境变量path

　　[T2] error：不能打开某个目录？ 可能是忽视了path环境变量中的目录的设置顺序。

　　[T3] Exception on thread “main” java.lang.DoClassDefFoundError:Test？没有设置classpath的路径。