这两天手下的项目经理病休了，其他人又不能很快接手，只好自己顶上作一些很久没有干过的具体工作了。干多了，还是有一些感慨的。
其中一个很深刻的体会就是：编码的习惯真的很重要。
比如：在我们的一个项目中，在一个功能模块中，要上线了，开始做贝塔测试了，发现系统在工作一段时间之后就会出现莫名其妙的错误。比如：点击一个链接之后没有任何反应，控制台没有任何异常。
程序员们分析了很久，仍然是一头雾水。我也是在客户身边，打开自己的程序员写的代码开始分析。压力很大。
认真分析之后，发现很多问题。其中，导致这个问题的，应该是从连接池获取数绝库连接之后没有归还。造成数据库连接池中没有数据库连结可用，还有就是获取到statement之后，也没有相应位置关闭这些语句，造成oracle的游标打开过多，最终耗尽资源，而停止服务。
此外，在try catch到系统异常之后，没有任何处理，甚至没有一个e.printStackTrace()，这样造成系统没有任何提示。
这些问题，其实都是编程习惯的问题，看似很小的问题，但是正是这些很小的问题，会让你在客户面前颜面扫地。所以，细节决定成败！这就是一个非常贴切的例证。
说了这么多，有点跑出技术的题外了。下面把网上找到的一个参考资料与大家共享一下吧。
很多朋友在Java开发中，使用Oracle数据库的时候，经常会碰到有ORA-01000: maximum open cursors exceeded.的错误。
实际上，这个错误的原因，主要还是代码问题引起的。
ora-01000: maximum open cursors exceeded.
表示已经达到一个进程打开的最大游标数。
这样的错误很容易出现在Java代码中的主要原因是：Java代码在执行conn.createStatement()和conn.prepareStatement()的时候，实际上都是相当与在数据库中打开了一个cursor。尤其是，如果你的createStatement和prepareStatement是在一个循环里面的话，就会非常容易出现这个问题。因为游标一直在不停的打开，而且没有关闭。
一般来说，我们在写Java代码的时候，createStatement和prepareStatement都应该要放在循环外面，而且使用了这些Statment后，及时关闭。最好是在执行了一次executeQuery、executeUpdate等之后，如果不需要使用结果集（ResultSet）的数据，就马上将Statment关闭。
对于出现ORA-01000错误这种情况，单纯的加大open_cursors并不是好办法，那只是治标不治本。实际上，代码中的隐患并没有解除。
而且，绝大部分情况下，open_cursors只需要设置一个比较小的值，就足够使用了，除非有非常特别的要求。
---
如果你不使用连接池，那么就没有什么问题，一旦Connection关闭，数据库物理连接就被释放，所有相关Java资源也可以被GC回收了。
但是如果你使用连接池，那么请注意，Connection关闭并不是物理关闭，只是归还连接池，所以PreparedStatement和ResultSet都被持有，并且实际占用相关的数据库的游标资源，在这种情况下，只要长期运行，往往就会报“游标超出数据库允许的最大值”的错误，导致程序无法正常访问数据库。
---
这个关不关和使用不使用conn pool没有关系，一般操作是会是这样，线程从外界获取一个conn，然后创建自己地stmt,rs,然后执行逻辑操作，然后将conn返回给pool。 如果程序员忘记手动关地话。当这个线程执行完以后，stmt，rs都成垃圾，当他们被垃圾搜集地时候，gc会替我们把它们给关闭地。这就是很多代码没有关闭，仍然正常运行。
但是这样会有一个潜在地问题。就是gc无法确定什么时候运行。如果free地内存很多，很可能有些gc就不会被启动，这样stmt迟迟没有被关闭，执行一段时间会报错。
所以健壮地代码应该手工把rs,stmt都关闭
---
Java连结Oracle常犯错误
1。只懂 createStatement,不懂关闭statement
2.。只懂 createStatement,不懂preparedStatement.
3 。只懂在sql里用to_date,甚至直接用String，不懂用 setDate()
---
我记得.我的程序中也出现过这种问题,
主要原因是我get Connection 对象后,这个connectin没有被进行关闭,
同时进行出来的 preparedStatement 对象,不关闭也会出现这种问题,
而且,推荐这些数据库操作的变量尽量用局部变量,现用现取,随时关闭,而且放在finally{}中进行关闭,
时间： 2024-10-13 17:19:40