# homework

**Repository Path**: xiaofan-zhang/homework

## Basic Information

- **Project Name**: homework
- **Description**: 临时作业
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-05-20
- **Last Updated**: 2022-05-20

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

	单线程正确性 [+50%]
+10%: 如果用户未初始化，我无法打开交易。
见TradingExecute类第50行，出现异常代表无法打开交易

+10%: 如果用户，出现在初始化地图上，我总能打开一个交易。
见TradingExecute类第27行，不出现异常代表可以打开交易

- 返回的totalAmount反映承诺的(被提交的?)金额。
见Bank类第79行

+15%: 提交交易(事务?)后，结果提供了进入账户的总变化。
- 返回的提交信息应该至少包含一个OperationType的操作(Operation of OperationType)。
见Bank类第136行

- 在向账户支付钱款后(把钱存入账户之后)，最后的总金额是之前的金额和正在支付的金额之和。
见Bank类第110行

- 我不能重新提交或中止一个已关闭的事务(交易?)。
见Bank类第104、117行

- 成功的操作应该包含提交之前的所有操作以及提交操作。
见Bank类第136行

+15%: 不允许透支。
- 我可以随时从我的账户中提取0.0的钱。
见Bank类TransactionCommands实现类的withdrawMoney方法

- 我永远不能提取超过我可以支配的金额的资金。(就是取的钱不能大于账户余额)
见Bank类TransactionCommands实现类的withdrawMoney方法

- 提交应列出所有的操作，从而包括透支的尝试。
见Bank类TransactionCommands实现类的withdrawMoney方法和commit方法，详情见ignoredOperationList和successfulOperationList两个list的操作

- 造成透支的操作不应视为失败的操作，而应视为被忽视的操作。
见Bank类第96行，添加ignoredOperationList忽略操作

	多线程正确性 [+40%]
+10%: 一个用户可以打开并发的交易(事务?)。
-  由于其他并发的事务还没有提交，每个线程只能看到自己账户中已提交的状态。
Bank类TransactionCommands实现类对象初始化时保存了各自的初始值


-  应允许任何用户在其账户中同时登录（例如，通过不同的可能设备）。
见Bank类第150行

-  没有write-write冲突。(不存在写写冲突)
见Bank类信号量实现互斥锁以及设置乐观锁

-  在假设用户的线程从未中止的情况下，银行账户中的最终金额对应于支付和取钱的总和。
见Bank类TransactionCommands实现类对象线程安全

+10%: 多个用户可以同时开启交易(事务?)。[与上述要求相同，加上以下内容：]
-  不同的用户永远不应该串行运行(不同的用户不应连续运行?)，因为他们在不同的账户上操作。[ 该代码可做出下面不切实际地假设：既不支付其他账户(既不向其他账户付款?)，也不从他们那里收到钱。]
Bank类第158行通过开线程处理交易

+10%: 不允许脏读。
- 一个线程决不能在提交后的总账户余额中看到在其他线程提交前支付/提取的资金数额。
Bank类TransactionCommands实现类对象初始化时保存了各自的初始值

- 一个线程永远不能提取其他未提交的线程所支付的钱。
Bank类TransactionCommands实现类对象初始化时查询到现有余额

- 被忽略的操作应该考虑到账户中不成功的提款。
见Bank类第82，92行


+10%:处理中止的事务:
- 来自中止的事务的操作应该被完全忽略/逆转(或者说是反转?)。
Bank类TransactionCommands实现类abort方法没有更新用户账户金额，故中止的事务的操作可以被完全忽略


- 特别地是，被中止的线程应该让银行处于一致的状态，因此进一步的交易会按预期运行。
Bank类TransactionCommands实现类abort方法没有更新用户账户金额，故不影响进一步的交易会按预期运行

	高级功能
- [+1%]银行被现实地模拟为一个分离的线程(银行被真实地模拟为一个独立的线程)。
Bank类实现了Runnable接口

- [+1%] 该代码利用了Java的并发集合。
Bank类中bankMap，blockingQueue，TransactionIdMap

- [+1%] 该程序允许直观地确定线程执行的操作的正确性（例如，终端打印或图形用户界面）。
引入了lombok框架

- [+1%] 该学生正确地利用了信号量。
见Bank类第170行

- [+2%] 一旦任何一个剩余的并发线程提交，一个线程就会感知到更新的账户余额。
通过Bank类中的volatile的bankMap

- [+2%] 该学生利用了乐观事务原则，操作被记录在日志中（在主内存或辅助内存中）。
见Bank类中TransactionIdMap

- [+2%] 监视器或多线程生产者和消费者的使用（信号灯也可能被利用）。
使用了生产者和消费者模式

- [+3%] 任何通过pom.xml导入的Java库 "不违反第三次提交要求"。
引入的junit-jupiter-api,logback-classic,lombok,fastjson未进行第二次修改

-[+4%] 除了前一点，银行线程崩溃也是可以容忍的，例如，所有的交易(事务?)都被假定为中止，银行日志被存储在磁盘上。
使用了生产者和消费者模式，银行线程崩溃，交易还是可以提交到队列中