我的架构经验系列文章 - 后端架构 - 语言层面
回到索引 http://www.cnblogs.com/lovecindywang/archive/2012/12/23/2829828.html
语言层面：
- 运行时元数据获取
所谓运行时元数据获取也就是在程序运行的时候通过代码动态获得类型、方法、属性的信息，然后可以动态获得属性的值，执行方法等等，在有的语言中称为反射。反射不一定是高效的，但是在写框架程序的时候反射是一种很有用的技术，并且反射的性能开销往往是可以通过诸如缓存等手段来最小化的。比如在ORM中，根据实体类的信息动态获得所有的属性，然后取得其值，生成要到数据库中执行的SQL语句。理解反射熟练掌握反射的使用以及性能优化是编写框架类代码很重要的一点。
- 错误处理
任何后端语言都有其错误处理机制，.NET和Java的异常处理机制也被更多的语言所吸纳，虽然每种语言的异常机制不一定都相同，但是也是大同小异。错误处理和异常处理的原则个人总结如下：
- 不要把错误的结果吃掉，不要把捕获的异常吃掉。所谓吃掉也就是针对错误结果或异常不做任何的处理，这样就没有人知道这个异常的存在这是很危险的。其实所谓异常就是代码不能执行代码语句本身所隐含的含义，比如有一个方法从名字上看是创建文件的，那么不能创建文件的时候方法应该是要抛出异常的，因为它办不了它应该办的事情，作为类库的编写者应该要这么做，有的时候出了问题我们会很迷茫为什么会出问题，作为类库的使用者应该在这样的方法周围进行异常处理，并且记录这样的异常，那么我们就很容易通过异常信息来找到根源问题，而不是去猜。有的时候根本没办法通过猜来解决问题，因为语言的类库是和操作系统打交道的一首环节，只有类库才知道操作系统有什么问题，比如是因为权限原因不能创建文件还是因为磁盘损坏，如果把这个异常信息舍弃的话是很难知道根本原因的。
- 具体怎么进行错误处理不能一视同仁需要看情况而定的。并且一般不建议直接捕获最大的异常，能细化的尽量细化，捕获所有异常意味着不能进行处理。一般情况下可以记录日志，或是重新包装后抛出，或是很明确地进行错误处理。
- 未处理的异常往往会随着调用栈往上升，升到最上层如果Web服务器发现异常还是未处理的话会导致各种颜色的错误页面。个人认为出现错误页面不一定是坏事情，很多人喜欢把所有的异常都吃掉不出现错误页，这不是解决问题的根本办法，根本办法是找到异常出现的原因，从代码角度解决它，而不是掩耳盗铃。当然，错误页是不应该让终端用户看到的，应该替换成友好的页面，在这个页面上可以什么都不写，也可以写一个异常ID，如果用户觉得这个操作是很要紧的话可以拿这个异常ID来和客服反馈，阐述其操作过程帮助我们解决问题，当然这个大前提是能把所有的异常都记录到数据库或方便查询的文本文件中。很多框架都具有统一收集未处理异常的入口点，在这里我们可以统一把未处理的异常汇总记录。
- 垃圾回收
除了C/C++之外大多数脚本语言和具有虚拟机的编译型语言都是自动垃圾回收的。虽然通过垃圾回收机制不需要手动来处理对象的释放，但垃圾回收不是万能的，可能是会导致内存泄露问题的。当然，这里说的内存泄露和C/C++的内存泄露其实不太一样，一般而言垃圾回收通过向上回溯对象引用根来判断对象是否可以被回收，如果我们程序写的不当导致对象始终存在引用根的话可能就会导致对象不能得到释放产生不断的内存膨胀，虽然说对象是存在指针指向的，并不是没有任何指针指向的野对象，但是其实我们是遗忘这个对象的，因此也可以说是是有内存泄露。因此，即使有垃圾回收我们也要特别注意一下静态对象的使用，是不是一定要是静态的，是不是可以是弱引用的，尽量避免使用声明周期过长的根。
- 多线程
大多数的编译型语言都支持用代码编写多线程，多线程是一个很有用的技术，可以用来让主线程、UI线程不因为其它操作停止响应，可以用来同时执行多个任务来提高任务执行的速度，充分利用多核CPU的处理能力，当然也可以把一个任务直接分割成多个任务并行执行，实现有多少CPU就可以执行多快。由于在编码的时候不能预测多线程的程序在执行时候的调度，所以我们在编码的时候就要特别小心多线程带来的问题：
- 如果多线程同时访问一个资源，比如同时对一个数字进行累加，那么很可能不到达到我们的预期。
- 类库所提供的类型不一定都是线程安全的，我们在使用的时候务必要阅读相关的资料确认是不是线程安全的，如果不是那么我们要通过诸如锁之类的手段来确保能够线程安全，否则很可能在调用类库的时候会出现异常或者说不能实现正确的代码。
- 多线程的程序调试起来也是比较麻烦的，因为多个线程可能会穿插执行不同的代码，此时我们可以通过记录日志、挂起某些线程或是临时切换为单线程程序来增加代码的调试性。
- 我们在编码的时候需要意识到什么是线程，一个线程所消耗的资源有多少，因为不要认为多线程可以提高效率，什么操作都用一堆线程来做，随便开启很多线程，这是得不偿失的，线程虽然比进程的代价小但是代价也不是这么小，因为每一个线程都有一个不小的线程栈，因此如果你发现你的程序开启了上千个线程的话，那么或许要想一下这样是否合理了。
- 在开启多线程的时候千万要记得不要遗忘这个线程，不要让线程在哪里什么都不干空循环，对于后台任务类线程，可以在一个地方记录我们程序中开启的线程，对于其它可以结束的线程，要确保线程中的代码能正常结束。
- 如果线程中的代码出现异常的话，大多数运行时或虚拟机会认为这是一个比较严重的问题，因为可能会导致整个系统中的状态不能保持一致，比如涉及到钱的系统这就是一个严重问题了，因此对于这种情况宁肯直接终止整个应用程序的进程也不要让这个问题没有人发现，错误的状态得到扩散，如果你觉得线程其实只是做一些无关重要状态的操作的话，务必确保线程不会出现未处理的异常。
- 代码生成
代码生成的作用很多，比如可以通过代码生成来减少我们代码的书写量，也可以通过代码生成实现AOP之类的切面操作。一般而言有两种代码生成的方式：
- 动态生成：代码是在程序运行的时候动态生成的，生成的代码在动态编译后动态加载到运行环境中动态执行，这比较适合根据程序的逻辑动态生成一些代码来执行，比如动态生成代理类，代理类的接口如果是事先无法确定的，那么我们也不可能在编译前就生成代码。
- 静态生成：一般是在编译前生成，然后直接进行编译的。比如自动根据XML中的相关数据定义生成CRUD的操作代码，既可以避免手写代码，又可以得到和手写代码相同的效率，因为这个代码其实还是死的还是固定的，并不是在运行时动态组织的，因此它的效率是最高的。
