哎
这个问题老让我不知道说什么
真的说，好像也不是没有，就是觉得说不出口，哈哈
1、服务器无端爆了（内存占用过高）
- 线程过多导致的，说明没有用线程池或者用了缓存线程池，或者用了指定数量过高的线程池
- 老年代gc频繁，是占用了大量资源的对象被移到了老年代；通常最好在新生代GC会快点
- 老版本的JDK中可能存在引用对象无法被GC的情况
2、死锁，由于设置了超时时间，所以在具有容错性的程序中并不会被明显感知
- 用到了多线程，并发
- 线程不安全的类 - （其实企业应用好像一般不是因为这个）
- 资源使用顺序问题，循环依赖（事务）
- 至少用使用乐观锁保证不产生脏数据
- 通过分解事务，和调整顺序等方式来规避
3、慢sql
- 距离排序超级慢，因为要读取出所有表记录（扫描全表），并计算距离 - 解决方式：折衷方案：1、通过分区域查询来减少查询数据量 2、通过缓存机制来避免一次查询缓慢的操作（因为用了阿里云的数据库，实际上数据库做了这个缓存功能，第二次查询就快了很多）
- 多表查询，超级复杂，且性能低下 - 采用solr将复杂度降低，也就是把多级结构变成单级结构，查询起来比较快（提现了一个恒久不变的规则：写的慢了，一般读的就快了）
- order by字段导致的查询缓慢问题 - 尽量不要使用函数、最好是有索引的字段、最好是数值类
4、第三方接口问题
- 坑爹第三方自己编码写死，还告诉我们错误的 编码。会不会吐血？因为HttpClient里面自动根据传回的编码格式解码，你说给我个错误的编码我能解码吗
- json数据传在参数中，没有写清楚。问题是有的json数据直接在body，有的在参数里面。是不是会被搞疯？
- 接口频率超限，明明是高频接口，却限制了频率，哭不哭？
- 机票出票失败有两个隐藏流程，第一次是供应商出票失败，第二次是平台重新分派出票失败。第二次才算真的失败。 不告诉你，你会知道吗？
顺便说句，我接过最好的接口是同程的火车票接口，人也很靠谱。
然后接的比较简单的是顺丰的接口，直接用WSDL生成代码，有的第三方示例代码都没有，不知道自己是怎么测试的
5、一些愚蠢的犯错
- 代码写死某个变量参数
- 没有判空，java8建议多用Optional
- boolean取反了
6、emjoy表情无法写入数据库 -修改数据库编码集或者过滤掉emjoy表情即可
7、Spring声明事务不生效
- 内部方法调用，事务是没办法生效的，为啥呢？因为AOP事务是通过代理的，内部的方法没有拦
- 多个嵌套的事务，有其中一个抛出异常，虽然捕获了，然而，还是会回滚
8、数据被错误覆盖了
- 其实就是并发的问题，脏数据 - 用乐观锁可以避免
解决的一些问题：
1、简化了一个商品页面的脚本代码，使得代码重新变得容易维护，封装了规格算法
2、提供了一个简单的订单模块的框架，大体上就是通过：模板模式来限定每个不同的订单模块需要实现的算法，比如确认订单、取消订单等，或者订单支付所要执行的所有步骤放到子类中去实现，具体的开发人员根据负责的模块去进行扩展；封装了支付方式：采用策略模式和静态工厂方法来提供不算支付方式的服务
3、将quartz并入分布式任务，不过说实话这块不好用；后续微服务也不太建议用这个方式