189 8069 5689
java程序大家都知道，内存溢出是经常见的错误，下面从基本的开始分析！
超过10多年行业经验，技术领先，服务至上的经营模式，全靠网络和口碑获得客户，为自己降低成本，也就是为客户降低成本。到目前业务范围包括了：网站设计、做网站，成都网站推广，成都网站优化，整体网络托管，小程序定制开发，微信开发，重庆App定制开发，同时也可以让客户的网站和网络营销和我们一样获得订单和生意！
内存溢出是由于没被引用的对象（垃圾）过多造成JVM没有及时回收，造成的内存溢出。如果出现这种现象可行代码排查：
一）是否App中的类中和引用变量过多使用了Static修饰 如public staitc Student s；在类中的属性中使用 static修饰的最好只用基本类型或字符串。如public static int i = 0; //public static String str;
二）是否App中使用了大量的递归或无限递归（递归中用到了大量的建新的对象）
三）是否App中使用了大量循环或死循环（循环中用到了大量的新建的对象）
四）检查App中是否使用了向数据库查询所有记录的方法。即一次性全部查询的方法，如果数据量超过10万多条了，就可能会造成内存溢出。所以在查询时应采用“分页查询”。
五）检查是否有数组，List，Map中存放的是对象的引用而不是对象，因为这些引用会让对应的对象不能被释放。会大量存储在内存中。
六）检查是否使用了“非字面量字符串进行+”的操作。因为String类的内容是不可变的，每次运行"+"就会产生新的对象，如果过多会造成新String对象过多，从而导致JVM没有及时回收而出现内存溢出。
如String s1 = "My name";
String s2 = "is";
String s3 = "xuwei";
String str = s1 + s2 + s3 +.........;这是会容易造成内存溢出的
但是String str = "My name" + " is " + " xuwei" + " nice " + " to " + " meet you"; //但是这种就不会造成内存溢出。因为这是”字面量字符串“，在运行"+"时就会在编译期间运行好。不会按照JVM来执行的。
在使用String,StringBuffer,StringBuilder时，如果是字面量字符串进行"+"时，应选用String性能更好；如果是String类进行"+"时，在不考虑线程安全时，应选用StringBuilder性能更好。
知道原因了，解决起来就非常简单了。
//SQL语句
12 var_dump($sql);
13 $res = mysql_query($sql);
14 $arr = array();
15 //吧结果存入数组 并记录数组长度
16 $count = 0;
17 while($data = mysql_fetch_array($res)){
18 $arr[$count] = $data;
19 $count++;
该参数值一直很高，且如果在 Physical Disk 计数器中，只有%Disk time 比较大，其他值都比较适中，硬盘可能会是瓶颈。若几个值都比较大， 那么硬盘不是瓶颈。若数值持续超过80%，则可能是内存泄露。如果 Physical Disk 计数器的值很高时该计数器的值（Processor%Privileged Time）也一直很高， 则考虑使用速度更快或效率更高的磁盘子系统。 Disk sec/Transfer 一般来说，该数值小于15ms为最好，介于15-30ms之间为良好，30-60ms之间为可以接受，超过60ms则需要考虑更换硬盘或是硬盘的RAID方式了。
大多数JAVA开发人员理所当然地以为性能优化很复杂，需要大量的经验和知识。
好吧，不能说这是完全错误的。
优化应用程序以获得最佳性能不是一件容易的事情。
但是，这并不意味着如果你不具备这些知识，就不能做任何事情。
这里有一些易于遵循的调优方式，湖北java培训建议可以做个参考！ 大部分建议是针对Java的。
但也有若干建议是与语言无关的，可以应用于所有应用程序和编程语言。
在讨论专门针对Java的性能调优技巧之前，让我们先来看看通用技巧。
1.在你知道必要之前不要优化 这可能是最重要的性能调整技巧之一。
你应该遵循常见的最佳实践做法并尝试高效地实现用例。
但是，这并不意味着在你证明必要之前，你应该更换任何标准库或构建复杂的优化。
在大多数情况下，过早优化不但会占用大量时间，而且会使代码变得难以阅读和维护。
更糟糕的是，这些优化通常不会带来任何好处，因为你花费大量时间来优化的是应用程序的非关键部分。
那么，你如何证明你需要优化一些东西呢? 首先，你需要定义应用程序代码的速度得多快，例如，为所有API调用指定最大响应时间，或者指定在特定时间范围内要导入的记录数量。
在完成这些之后，你就可以测量应用程序的哪些部分太慢需要改进。
然后，接着看第二个技巧。
2.使用分析器查找真正的瓶颈 在你遵循第一个建议并确定了应用程序的某些部分需要改进后，那么从哪里开始呢? 你可以用两种方法来解决问题： ·查看你的代码，并从看起来可疑或者你觉得可能会产生问题的部分开始。
·或者使用分析器并获取有关代码每个部分的行为和性能的详细信息。
希望不需要我解释为什么应该始终遵循第二种方法的原因。
很明显，基于分析器的方法可以让你更好地理解代码的性能影响，并使你能够专注于最关键的部分。
如果你曾使用过分析器，那么你一定记得曾经你是多么惊讶于一下就找到了代码的哪些部分产生了性能问题。
老实说，我第一次的猜测不止一次地导致我走错了方向。
3.为整个应用程序创建性能测试套件 这是另一个通用技巧，可以帮助你避免在将性能改进部署到生产后经常会发生的许多意外问题。
你应该总是定义一个测试整个应用程序的性能测试套件，并在性能改进之前和之后运行它。
这些额外的测试运行将帮助你识别更改的功能和性能副作用，并确保不会导致弊大于利的更新。
如果你工作于被应用程序若干不同部分使用的组件，如数据库或缓存，那么这一点就尤其重要。