java代码优化解决高并发下的问题

一种是使用缓存、另一种是使用生成静态页面；还有就是从最基础的地方优化我们写代码减少不必要的资源浪费：(

1.不要频繁的new对象,对于在整个应用中只需要存在一个实例的类使用单例模式.对于String的连接操作,使用StringBuffer或者StringBuilder.对于utility类型的类通过静态方法来访问。

关于new对象就不用多说了吧，new一个对象等于开辟一个新内存。

因为String对象一旦创建是不能改变的，总的来说StringBuffer比String在效率上的优越的。比如你执行了String类的substring，replace，toUpperCase，toLowerCase，trim方法都会生成一个新的字符串，一旦你的程序对字符串有大量修改，那么在jvm的堆内存中就会生成大量的旧的临时垃圾字符串对象。String如果长度发生改变，是非常消耗内存的。
我们先来看一些String类的基本特点：

（1）string是不可变的是被final修饰的，带来的好处主要有两点，第一是线程安全，可以在多个线程中共享而不需要加锁，第二是由于不变性所以它的hashcode可以被缓存后提升效率，这也是为什么我们见到的大多数的HashMap的key都是使用String类型的。

（2）通过双引号定义的字符串我们称为字符串字面量，这部分字符串会被在string pool中创建，在java里面比较一个对象相等，应该优先选择equals方法而不是==方法

（3）对于字符串拼接的 + 号，底层其实是使用StringBuffer 或者 StringBuilder来完成的。

而StringBuffer跟StringBuilder该如何取舍呢？
都知道StringBuffer跟StringBuilder线程最大的特点一个安全一个不安全，以及运行速度的问题
那StringBuffer跟StringBuilder的应用场景是什么呢？
最简单的回答是，stringbuffer 基本没有适用场景，你应该在所有的情况下选择使用 stringbuiler，除非你真的遇到了一个需要线程安全的场景，关于线程安全，即使你真的遇到了这样的场景，很不幸的是，恐怕你仍然有 99.99…99% 的情况下没有必要选择 stringbuffer，因为 stringbuffer 的线程安全，仅仅是保证 jvm 不抛出异常顺利的往下执行而已，它可不保证逻辑正确和调用顺序正确。大多数时候，我们需要的不仅仅是线程安全，而是锁。为什么会有 stringbuffer 的存在，如果真的没有价值，为什么 jdk 会提供这个类？答案太简单了，因为最早是没有 stringbuilder 的，sun决定让 stringbuffer 是线程安全的，然后大约 10 年之后，人们终于意识到了，于是，在 jdk1.5 的时候，终于决定提供一个非线程安全的 stringbuffer 实现，并命名为 stringbuilder。顺便，javac 好像大概也是从这个版本开始，把所有用加号连接的 string 运算都隐式的改写成 stringbuilder，也就是说，从 jdk1.5 开始，用加号拼接字符串已经没有任何性能损失了。
如诸多评论所指出的，我上面说，"用加号拼接字符串已经没有任何性能损失了"并不严谨，严格的说，如果没有循环的情况下，单行用加号拼接字符串是没有性能损失的，java 编译器会隐式的替换成 stringbuilder，但在有循环的情况下，编译器没法做到足够智能的替换，仍然会有不必要的性能损耗，因此，用循环拼接字符串的时候，还是老老实实的用 stringbuilder 吧。

2.避免使用错误的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof做条件判断,尽量使用比的条件判断方式.使用JAVA中效率高的类,比如ArrayList比Vector性能好。)

instanceof通过返回一个布尔值来指出，这个对象是否是这个特定类或者是它的子类的一个实例。 （后续还有更新）